Kernel Traffic #1 For 14 Jan 1999

By Zack Brown

Table Of Contents

• Printer-Friendly Format
• Text Format
• XML Source
• Introduction
• Mailing List Stats For This Week
• Threads Covered

  1.	11 Jan 1999 - 12 Jan 1999	(3 posts)	Spam On linux-kernel
  2.	12 Jan 1999 - 14 Dec 1999	(35 posts)	Crypto Restrictions
  3.	8 Jan 1999 - 12 Jan 1999	(60 posts)	Porting The vfork() Syscall
  4.	8 Jan 1999 - 14 Jan 1999	(54 posts)	C Or C++ For Kernel Code?
  5.	8 Jan 1999 - 11 Jan 1999	(9 posts)	GCC or EGCS?
  6.	8 Jan 1999 - 11 Jan 1999	(8 posts)	Listing File Inode Numbers
  7.	8 Jan 1999 - 10 Jan 1999	(12 posts)	zImage Vs. bzImage
  8.	8 Jan 1999 - 13 Jan 1999	(34 posts)	linux-kernel Slowdown
  9.	8 Jan 1999 - 12 Jan 1999	(19 posts)	Are Distributions Ready For 2.2?
  10.	8 Jan 1999 - 13 Jan 1999	(17 posts)	Mounting Compressed Filesystems
  11.	9 Jan 1999 - 14 Jan 1999	(67 posts)	Recursive Semaphores In The Kernel

Introduction

This is the first issue of Kernel Traffic, a free publication that aims to provide a take on some of the activities of the Linux Kernel mailing list. We liked the layout of the Linux Weekly News so much we just outright copied it. Hopefully we'll one day be able to live up to their high quality as well.

Kernel Traffic will not cover everything on the list, and there will also be spillage from one week into the next. That's just the way it goes. Trying to keep track of something as amazing as the linux kernel mailing list is not going to be easy. Please bear with us and help us with submissions.

Our format and layout will probably fluctuate as we get our bearings and struggle to cope with the enormous volume of the mailing list; but for the moment, our plan is to keep it simple: a single page, with headings covering various subjects discussed on the list each week. We may also eventually present some general discussion and some informal statistics such as approximately how many messages there were through the week and so on.

How you can help: Sometimes we'll have questions of our own. Send us your answers, and we'll include the clearest and most complete ones in our "Read More" pages, which will (hopefully) grow throughout the weeks following publication. Sometimes we won't have a question but we'll just get something wrong. Tip us the wink and we'll slip in your correction.

How else you can help: Write up summaries of kernel mailing list threads and send them to us. We'll include the best ones in our main page with your name on top. Try to explain the technical issues as well as the merits of each side's perspective. Preference will be given to articles which involve some pivotal issue, and explanations of nonpivotal technical discussions.

By the way, we'll be taking submissions for our title graphic for awhile. Help us out with your gimp skills.

Unfortunately this page is being hosted by a student account, with no fancy gadgets like cgi or lots of storage space. If anyone wants to give us a nice big space with cgi, a snappier URL and better bandwidth, please drop us a line.

We hope you like this project. It's something we've had on our minds for awhile, and now we're doing it.

Mailing List Stats For This Week

We looked at 1556 posts in 5851K.

There were 542 different contributors. 256 posted more than once. 75 posted last week too.

The top posters of the week were:

• 75 posts in 207K by (Alan Cox)
• 40 posts in 147K by Linus Torvalds
• 33 posts in 163K by Andrea Arcangeli
• 31 posts in 114K by "Stephen C. Tweedie"
• 31 posts in 113K by Jamie Lokier
• Full Stats

1. Spam On linux-kernel

11 Jan 1999 - 12 Jan 1999 (3 posts) Archive Link: "MAKE MONEY WHILE YOU SLEEP"

Topics: Mailing List Administration, Spam

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.

2. Crypto Restrictions

12 Jan 1999 - 14 Dec 1999 (35 posts) Archive Link: "US relaxes crypto restrictions?"

Topics: Compression, Legal Issues

People: Linus Torvalds

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.

3. Porting The vfork() Syscall

8 Jan 1999 - 12 Jan 1999 (60 posts) Archive Link: "Re: Porting vfork()"

Topics: BSD: NetBSD, System Calls

People: Linus Torvalds

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?

4. C Or C++ For Kernel Code?

8 Jan 1999 - 14 Jan 1999 (54 posts) Archive Link: "Re: C++ in kernel"

Topics: Preferred Language

People: Linus Torvalds

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?

5. GCC or EGCS?

8 Jan 1999 - 11 Jan 1999 (9 posts) Archive Link: "Official kernel stance on EGCS?"

Topics: Compiler

People: Linus Torvalds

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.

6. Listing File Inode Numbers

8 Jan 1999 - 11 Jan 1999 (8 posts) Archive Link: "Re: ext2 tool"

Topics: FS: ext2

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 /

7. zImage Vs. bzImage

8 Jan 1999 - 10 Jan 1999 (12 posts) Archive Link: "Re: System is too big. Try using bzImage or modules."

Topics: Compression, Preferred File Format

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?

8. linux-kernel Slowdown

8 Jan 1999 - 13 Jan 1999 (34 posts) Archive Link: "Re: linux-kernel's extremely slow turnaround time"

Topics: Mailing List Administration, Popularity

People: Matti Aarnio, David S. Miller, Chris Wedgwood, Linus Torvalds

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.

9. Are Distributions Ready For 2.2?

8 Jan 1999 - 12 Jan 1999 (19 posts) Archive Link: "Re: [Off-Topic] Distribution 2.2-ready"

Topics: Upgrading

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.

10. Mounting Compressed Filesystems

8 Jan 1999 - 13 Jan 1999 (17 posts) Archive Link: "Re: new filesystem: zipfs"

Topics: Compression, FS

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.

11. Recursive Semaphores In The Kernel

9 Jan 1999 - 14 Jan 1999 (67 posts) Archive Link: "MM deadlock [was: Re: arca-vm-8...]"

Topics: SMP

People: Linus Torvalds

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?

Sharon And Joy