Kernel Traffic

This issue of Kernel Traffic is dedicated to my grandmother, Mildred Brown, Sept 23, 1908 - March 5 2002.

Ioctls

Rusty Russell felt that 2.5 would be a good time to make use of one of the user-space semaphore implementations that were available. He posted his own patch, explaining:

This version uses wli's multiplicitive hashing. And it has these yummy properties:

Interface is: open /dev/usem, pread, pwrite.
No initialization required: just tell the kernel "this is a semaphore: down/up it".
No in-kernel arch-specific code.
Locks in mmaped are persistent (including across reboots!).

Ingo Molnar felt that patch was good, but disliked the interface. He said, /dev/usem is such an ... ioctl()-ish approach. He suggested, Why not new syscalls? I think these lightweight semaphores will become an important part of Linux, so having their own syscall entries is the most correct interface. Something along the lines, he went on, of sys_sem_create(), sys_sem_destroy(), sys_sem_down(), and sys_sem_up(). And Linus Torvalds added, I agree - I dislike magic device files a whole lot more than just abotu every alternative. Rusty said he'd do a syscall-based implementation, and see if I can actually get it to beat fcntl locking on reasonable benchmarks (ie. tdbtorture).

He and Linus went back and forth on the implementation for a bit, disagreeing on the precise semantics. At one point Linus said:

I would personally actually prefer an interface more like

fd = sem_initialize();
mmap(fd, ...)
..
munmap(..)

which gives you a handle for the semaphore.

Note that getting a file descriptor is really quite useful - it means that you can pass the file descriptor around through unix domain sockets, for example, and allow sharing of the semaphore across unrelated processes that way.

Also, the fd thus acts as an "anchor" for any in-kernel data structures that the semaphore implementation may (or may not) want to use. Think of it as your /dev/usem, except with a more explicit interface.

And make the initial mmap() only do a limited number of pages, so that people don't start trying to allocate tons of memory this way.

Ioctls Real-Time Sound: ALSA Pavel Machek Jaroslav Kysela

Jaroslav Kysela posted a patch to allow the kernel to make use of the RTC timer. This would be useful, he said, for the ALSA sequencer. Pavel Machek pointed out that this would leave architectures like Sparc and Alpha, that don't have RTC, out in the cold. Jaroslav replied that the default would be to use the existing kernel-space timer, but that the kernel could make use of the RTC if it was available. Roman Zippel felt that could easily use the RTC without modifying the kernel, and showed a way to do it:

This patch can also be done in userspace:

fd = open("/dev/rtc",...);
ioctl(alsafd, RTCFD, fd);

in the alsa driver you can do:

file = fget(fd);
...
if (file->f_op && file->f_op->ioctl)

file->f_op->ioctl(file->f_dentry->d_inode, file, cmd, arg);

...
fput(file);

Jaroslav said that the driver would also need a callback called at interrupt time, and Roman replied that this could be done with a task queue. There was no reply.

Justin Piszcz Daniel Quinlan Bruce Holzrichter

Marcelo Tosatti announced 2.4.18, but then discovered that he had forgotten to include 2.4.18-rc4 in that release. He said he'd fix it in 2.4.19-pre1, but Daniel Quinlan suggested just putting out 2.4.19 with only that patch applied. He pointed out that there was no harm in doing an extra release, but Marcelo felt it wasn't an important enough error to justify that. Meanwhile, Justin Piszcz took a look at 2.4.18 and seemed to find evidence of the rc4 patch, but Dave Jones said, Only 1 chunk got dropped, not all of rc4. Check the rc4-final diff in testing/incr/ and apply with -R.

Elsewhere, Bruce Holzrichter suggested tagging 2.4.18 with a '-dontuse' suffix on the download site, but Marcelo said, No. A "-dontuse" tag should be only used when the kernel can cause damage in some way. The patch which I missed only breaks static apps on _some_ architectures (not including x86). He added that he'd changed the Changelog to say, "Update: The SET_PERSONALITY fix in rc4 has _not_ been included in the final 2.4.18 by mistake."

Bernd Eckenfels and Hilsen Harald agreed with Daniel. As Bernd put it, I dont understand why it is a problem to release 2.4.19 instead. Close by, Stephan von Krawczynski also felt that Marcelo was giving short shrift to non-x86 machines. He said, You obviously classify these architectures as minor important. At least not important enough to give them a release version as bugfree as possible at the given time. You shouldn't do that, don't focus on what you classify the "mainstream" too much. As stated before, there is no problem with making mistakes. You only have to handle the situation in an intelligent manner _and_ aware of the power given to you. In my eyes, the clean choice would have been 2.4.19 release.

Rik van Riel said that Stephan should put out a 2.4.19 himself if he wanted to. He said, It's just too easy for people to critisise marcelo without realising how much work he's putting into 2.4. Stephen replied, This comment was suboptimal, Rik. There is a group of people that can _make_ one, but there is only one that can _release_ it. No need to discuss if I am a member of the group, but for sure neither me nor you are _the one_. So we both can do no more than state our personal opinions on the matter.

Elsewhere, someone suggested just putting out a corrected version of 2.4.18; Marcelo said this would cause problems with the FTP site mirroring system. David S. Miller remarked, We can avoid this kind of mess in the future if the "-rc*" releases really are "release candidates" instead of "just another diff". Ie. they are done as patches _and_ tarballs, then the final can just be done with a "cp" command. That will make errors like this one more likely to be caught. But Thomas Duffy pointed out that the top-level makefile still had to be changed to reflect the new version number. Leaving out the -rc from release candidates, he said, would cause confusion. He said, the last thing I want is to be running a 2.4.18-rc3 kernel and have uname tell me it is 2.4.18. David replied:

I think the benefits of not screwing up the real release are larger than this inconvenience.

As a side note I also think it's silly that we can't just "fix up" when a slight error is made like this. In the worst possible case one could make a real quick "2.4.18a" release that had things fixed.

Personally I'd just put fixed files up and say "sorry the original one didn't have the holy penguin pee on it, this one does" and tell people to simply cope.

Elsewhere, yet more folks said that releasing 2.4.19 would have been the correct solution.

Michael Cohen

Michael Cohen collected a bunch of patches and cleaned them up to apply properly against 2.4.19-pre1. Among other things, he included a patch that might consume all unassigned block device major numbers. Alan Cox said, As discussed before - this is a bad idea. Please don't regurgitate random incorrect patches - it doesnt help. Richard Gooch (original author of the patch in question) replied, No, Alan. *You* don't think this is a good idea. Not everyone agrees with you. My patch is safe: it makes use of the safe major allocation function so that >128 SD's can be used. You seem to be against this patch because it would mean that you can't just keep handing out major numbers, ignoring Linus' "no new majors" decree. Alan replied, Linus no new numbers decree was irrelevant. You can live in your little ivory tower if it makes you happy, but everyone else works off the post Linus devices.txt maintained by LANANA.

Marcelo Tosatti

Christer Weinigel posted a patch to add support for the National Semiconductor SC1200, SC2200 and SC3200 families of processors to the Linux kernel. Marcelo Tosatti replied that the patch wouldn't apply cleanly to his tree, probably due to other patches Christer had been using on his own. Christer posted a new patch against the latest pre-release.

Framebuffer Marcelo Tosatti Ani Joshi Michael Cohen

Michael Cohen posted a patch for 2.4, for the RivaFB driver. Marcelo Tosatti replied that he should submit it to the RivaFB maintainer first. Jeff Garzik replied, to be honest there really isn't one..... Marcelo pointed out that Ani Joshi was the official maintainer, but Jeff said, Ani volunteered for the position, then has been ignoring patches sent to him for a year or more. I used to be rivafb maintainer (look at who wrote riva/fbdev.c...), then didn't have time. When I asked around for a new maintainer, he claimed to take up the position, but no patches have been forthcoming... He added, Ferenc Bakonyi did a good bit of work, and IMO would be a good candidate for maintainership, if he's still around. Marcelo replied that he'd been receiving and applying RivaFB patches from Ani, and Jeff said, That's great! I'm glad he's returned. End of thread.

Pete Zaitcev noticed that s390 support was broken in the kernels leading up to and going beyond 2.4.18. He posted a fix, and Martin Schwidefsky of IBM replied, The patch that was merged in 2.4.18-pre* has been created against 2.4.17-pre7 and it did work. The problem is that not all of the changes I sent Marcelo have been accepted. One of the patches was the asm-offsets fix that removes all of the hardcoded offsets from entry.S. Another patch was accepted that changed the thread structure and this created the inconsistency. Pete replied, Please keep poking Marcelo with it, and it's a great pity that you did not before 2.4.18 came out.