Some get-rich-quick spam hit the list this week. Not as much as you might expect, but enough to be annoying. Someone gave a pointer to Junkbusters, and added that they had forwarded the offending messages to uce@ftc.gov, which they said was the place where the Federal Trade Commission collects unsolicited commercial email (UCE). They added that forging a return address on a commercial solicitation or not giving a valid way to be removed from the list was illegal in the United States, and that the FTC would prosecute folks who violated those laws.

Alexander Kjeldaas gave a pointer to this article about how the US will change its crypto laws. The effect of this on kernel development seems to be that cryptography, currently a separate patch you have to apply yourself, might be incorporated directly into the kernel.

The snag is that countries like France would then be unable to use linux because of their own restrictions. This would also impact their recent decision to use linux in their school system.

Various ideas were brought up about how to get around this, including having crypto code masquerade as compression code (it's not our fault if people use compression hooks for encryption, right?), but nothing received overwhelming support. Linus Torvalds had no comment on whether crypto will go into the kernel as a result of this new development.

This was one of the biggest threads on the list this past week, continuing from an earlier thread the week before. Apparently the question is whether linux should implement the traditional vfork() function, or continue to rely on the existing fork() and clone() functions. According to the manpage, vfork() in linux has until now been just an alias for fork().

The decision seems to have been made in the latest kernels to go ahead with it, and the discussion is moving toward implementation details. Linus Torvalds' sense of it could be seen in this quote: vfork() is a lot easier to use than clone() (you don't need to know about threading, because everything is basically single-threaded as far as the application is concerned - the only entity that needs to know about vfork() is basically the compiler, because vfork() has setjmp() like properties when it comes to automatic variables). In a different post, he added, Note that vfork() is only an abomination because it can be hard to get right - and we don't have that problem any longer. Basically everybody hates it not because it's an ugly interface, but because it's so hard to implement. And that's a big conceptual difference.

There is a NetBSD page discussing this issue. The issue seems to be primarily of speed, but in terms of implementation there are all sorts of hairy things like race conditions, deadlocks, and semaphores to worry about.

There's an informative page about OS design that discusses these things. Basically a race condition is where several processes may accomplish a task, and the program's behavior should be different depending on which process finishes first. A deadlock is when two processes are each waiting for a signal from the other, so neither can proceed. A semaphore allows only one process to do something at a time, so the others must wait until the first moves on. There are also things called recursive semaphores, which are beyond me. Would someone like to write up a clearer explanation of these things and how they relate to the issues involved in the (now nearly resolved) vfork() debate?

This is one of those discussions that never really dies, and sometimes flares up out of nowhere. Should the kernel use C++ or stick with C? This seems to be one of the things that may cause a code fork eventually.

There seem to be many intertwining issues, including the possibility of using some subset of C++ that is "better" than C but doesn't have the "problems" of the full C++ language. There's also the question of who will be writing device drivers, in terms of what their skill level will be.

One argument in favor of C++ adoption is that object orientation can insulate programmers from some of the more difficult areas of kernel development.

The opposing argument is that the insulation of object oriented programming (OOP) would turn out to be an illusion in those difficult areas, since performance would depend on a thorough knowledge of the internal operation of the code and how it is compiled.

The bottom line, for now, is that Linus Torvalds is not going to switch to C++, so the discussion is basically moot. Still, it's very interesting to try and understand the different sides and nuances.

Would someone be willing to write up a more complete summary of the different issues involved?

Like the C++ issue, this is also one of those ongoing debates that never really dies. Essentially, there are two compilers: gcc and a code-fork of gcc called egcs, which is the only one under active development. Somewhere along the line egcs stopped being able to compile the linux kernel, which caused enormous contention among developers. Some people said that the kernel code was incorrect and that egcs was simply correcting the bad behavior of gcc which the kernel had adapted to, while others said that the compiler should remain backwardly compatible with gcc and not require painful code rewrites.

The current situation appears to be that Linus Torvalds is willing to take kernel patches that resolve the conflict, so eventually egcs may become the standard for compiling the kernel. As far as who was right and who was wrong in the whole theoretical debate, I think both sides had their points and it was an awful conflict from beginning to end. I'm relieved to see it finally start to fade away.

Someone asked if there was a tool to give the filename corresponding to a given inode, for the 'ext2' file system. They wanted it to print out the inode number, the full path and file name, and the inode type.

There were a number of replies giving one liners to accomplish it. One of the simplest was:

ls -alFRi /

Apparently there is some question as to whether support for 'zImage' kernels should be dropped in favor of the 'bzImage' format. As was pointed out on the list, zImage kernels are compressed (zipped) kernel images, while bzImage files are "big zipped" (as opposed to "bzip", the popular compression program). The difference between the zImage and bzImage is that bzImage kernels don't have the 512K limit imposed by zImage files.

Unfortunately, bzImage kernels don't work on all systems. This is a problem for RedHat users, since RedHat includes only bzImage kernels in their distributions. The problems people have with that kernel seem infrequent enough that RedHat may not change their policy (though they haven't made any statements about it), and zImage files may be dropped. It's still an open question. For now, however, zImages can still be made.

Could someone clear up the question of why the 512K limit exists for zImage files?

The linux-kernel list seems to be very slow distributing its messages lately. Some interesting information came out of the discussion: as Matti Aarnio put it, the mailing list is hosted by a SparcStation10/50MHz, 128 MB RAM with 50 MHz SuperSparc. Average load-average is 5 to 10, and only one process is doing email routing -- e.g. it is getting 10-20% of CPU to do that task. Matti Aarnio also maintains the zmailer program which (as opposed to sendmail) handles the list.

David S. Miller, who runs the list, said he is looking for a long term solution. As an aside, he added that subscription had tripled when Linus Torvalds announced the 2.2.0pre series. Chris Wedgwood said that a recent count of subscribers reached 3015. This may or may not have been before or after the 2.2.0pre announcement.

Some folks started wondering whether various distributions would be able to run 2.2.0; apparently various people have gotten the latest kernels working on pretty much all the different distributions, but that's not the same as saying they'll work for everybody, or that all parts of a distribution will work with a given kernel. We'll have to wait and see.

Someone wants to be able to mount compressed files (.zip, .tgz, .tbz2, etc) as regular directories. Apparently midnight commander can handle this, to some extent. Userfs was a project that might have handled it, but it hasn't been worked on in a while, apparently.

Some high powered debugging took place on this thread. Wish I Understood More (tm).

Linus Torvalds: This one is a whole lot harder to fix - the previous one needed only a simple extra flag, this one is truly nasty.

The next paragraph: The cleanest solution I can think of is actually to allow semaphores to be recursive. I can do that with minimal overhead (just one extra instruction in the non-contention case), so it's not too bad, and I've wanted to do it for certain other things, but it's still a nasty piece of code to mess around with.

In a different part of the thread, Linus said he was starting to despair of finding a good recursive semaphore implementation.

Anyone care to explain this to us mortals? What is a recursive semaphore? What implementations have been tried? Why were they insufficient? Why is the problem so difficult?