Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #279 For 20 Oct 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1691 posts in 9995K.

There were 430 different contributors. 235 posted more than once. 182 posted last week too.

The top posters of the week were:

1. Linux 2.6.9-rc2-mm1 Released

16 Sep 2004 - 23 Sep 2004 (39 posts) Archive Link: "2.6.9-rc2-mm1"

Topics: Kernel Release Announcement

People: Andrew MortonJesse Barnes

Andrew Morton announced Linux 2.6.9-rc2-mm1, saying:

Norberto Bensa pointed out that one of the patches Andrew had accepted would break Nvidia's binary-only driver, and that Nvidia users would have to revert the patch in order to use the driver.

Jesse Barnes also noticed that some of the changes in -mm1 broke sn2; and some folks worked on that.

Miscellaneous other breakages and fixes were discussed, as usual.

2. Linking Drivers With Modules In SysFS

20 Sep 2004 - 26 Sep 2004 (12 posts) Archive Link: "[RFC] put symbolic links between drivers and modules in the sysfs"

Topics: FS: initramfs, FS: ramfs, FS: sysfs, USB

People: James BottomleyGreg KHAlexander Viro

James Bottomley said:

This functionality is essential for us to work out which drivers are supplied by which modules. We use this in turn to work out which modules are necessary to find the root device (and hence what initrd/initramfs needs to insert).

If you look at debian at the moment, it uses a huge mapping table on /proc/scsi/* to do this. If we implement the sysfs feature, we can simply go from /sys/block/<device> to the actual device to the driver and then to the module with no need of any fixed tables.

The code is a first cut and introduces two new module APIs: module_add_driver() and module_remove_driver(). We need this because the generic device model driver has no current knowledge of modules. We could enhance it to have a struct module * in struct device_driver, but once we have the sysfs links which this patch provides, there didn't seem to be a compelling reason to add it to struct device_driver.

Greg KH replied, "I like it. But I do think that this should be moved into the driver core, so I added a "struct module *" to "struct device_driver". Here's the patch that I just applied to my trees, based on yours. It is only the core changes (and yes, I did fix up the location of the functions in the module.h file and fixed the bug when modules were not configured in.) I'll post my usb core change after this, to show you how USB can be hooked up to it. I'll let you figure out what the best way to handle the scsi code would be." He posted his patches, but there was no discussion.

Elsewhere, Alexander Viro had his own objections. He said to James:

So what will your userland code do when you run it on a system with non-modular kernel currently running?

IOW, that's a fundamentally broken interface - you really want the same information regardless of modular vs. built-in.

Greg replied, "I agree, and Rusty has some pending patches that provide that information for all drivers built into the system. When they are merged, this symlink will be created for those also (with a bit of tweaking, but it will happen.)" Herbert Xu also agreed with Alexander's objections, and was glad to see this being worked on in this thread. James, however, disagreed with Alexander that the interface was broken, though he agreed the module parameters might have some issues. But there wasn't much discussion.

3. ipchains And ipfwadm To Be Removed; iptables Replacing Them, But Not Yet Fully Ready

20 Sep 2004 - 23 Sep 2004 (27 posts) Archive Link: "[PATCH] Warn people that ipchains and ipfwadm are going away."

Topics: Backward Compatibility, Spam, Virtual Memory

People: Rusty RussellBill DavidsenRichard B. JohnsonWilliam StearnsAndi KleenDavid WoodhouseAlbert CahalanMatthew GarrettDavid S. Miller

Rusty Russell put some comments in the code to warn folks that ipchains and ipfwadm were deprecated and would be removed soon. He said:

At the recent netfilter workshop in Erlangen, we was decided to remove the backwards compatibility code for ipchains and ipfwadm. This will allow significant cleanup of interfaces, since we had to have a mid-level interface for the backwards compatibility layer to use.

Start off with a warning for 2.6.9, so any remaining users have a chance to migrate. Their firewall scripts might not check return values, and they might get a nasty surprise when this goes away.

Bill Davidsen remarked:

I thought I understood the "new development model" but I guess I don't. Are working features now going to be removed from the "stable" chain instead of during a development cycle?

Not a complaint, I thought the new method was regarding new features...

There was no response here, but elsewhere Marc Ballarin pointed out that Rusty's comments were compile-time only, and would thus probably be missed in the long stream of compile-time warnings put out by standard kernels. Rusty replied, "Sure, but you have to start somewhere. Next step will be #error. Then finally remove the whole thing (I don't want to remove the whole thing to start with, since that would create a silent failure)." Marc said he was thinking of a prominent message at module load time; but the discussion skewed off.

Close by, Richard B. Johnson asked, "What replaces the firewall stuff? It can't just "go away"!" James Courtier-Dutton and Marc replied that iptables had already been the standard since 2001. Martin Josefsson also pointed this out, but Richard replied that old code still depended on the old mechanisms. He said:

I guess I'll have to convert 1340 lines of ipchains commands to iptables -yech!

I had convert something to ipchains a couple of years ago. That's when I only had to kill-off only about 100 spam-hosts.

Now I gotta convert again. Soon they'll be replacing `ls` with `echo *` and nothing will work.

William Stearns replied:

I have a script that does a first pass of converting an ipchains firewall script to an iptables firewall script at

Because of architectural differences between the two firewall technologies it can't produce a perfect translation, but it does handle most of the grunt work.

Close by, Andi Kleen also pointed out that "doesn't have usable 32bit emulation on x86-64. 32bit userland on x86-64 kernel cannot use iptables, they have to use ipchains. I would ask for to not drop ipchains until this is fixed." David Woodhouse agreed with this, saying, "The iptables compatibility with 32-bit userspace is completely broken." But Albert Cahalan objected, "Who is doing a 32-bit userland on x86-64, and WTF for? Why do they not also run a 32-bit kernel?" Matthew Garrett replied, "Debian will be shipping a 32-bit userland with a 64-bit kernel. The reasons are long, awkward, and mostly uninteresting. The reason for shipping a 64-bit kernel is that it makes it easier for users who require large quantities of VM to obtain it." David S. Miller said, "But just like the sparc64 port, there is a 64-bit userland compilation environment available, and debian has the means to ship 64-bit specific packages on top of a mostly 32-bit userland. So it is very easy for them to ship a 64-bit netfilter utility package if they wanted to."

4. Staircase Scheduler Version 8.6 Released

23 Sep 2004 (1 post) Archive Link: "[PATCH] Staircase scheduler v8.6"

People: Con Kolivas

Con Kolivas said:

Updated the staircase cpu scheduler. This version is the first in the next development phase I've been leading it towards - removing dependency on scheduler_tick to make it suitable for a tickless kernel.

v8.6 removes all timeslice expiration from scheduler_tick and does this with an on-demand timer of it's own. Currently this does not offer any major advantage over the previous version, but once more of the code is removed from scheduler_tick and there is a mechanism for more accurate timers not dependant on jiffies it will offer better accuracy, lower overhead and low power advantages.

Rolled up and split patches for 2.6.9-rc2-mm2 available here:

5. Linux 2.6.9-rc2-mm3 Released

24 Sep 2004 - 27 Sep 2004 (38 posts) Archive Link: "2.6.9-rc2-mm3"

Topics: Kernel Release Announcement, Version Control

People: Andrew MortonDmitry Torokhov

Andrew Morton announced Linux kernel 2.6.9-rc2-mm3, saying:

6. Autofs NG 0.1 Released

24 Sep 2004 - 29 Sep 2004 (3 posts) Archive Link: "[announce] Autofs NG 0.1"

Topics: FS: autofs, Version Control

People: Mike WaychisonStew Smith

Mike Waychison said:

Some of you may remember my posting of a new way to do autofs in Linux a while back:

Anyhow, I've gotten to the point where I have code that people can play with. I've posted it all at

There are two repos located there, one is the userspace bits (autofsng). ~ It has the 'utility' (automount) and the autofs usermode agent (autofs). This tree began as a automount 3.1.7 tree, but has drastically changed. Lots of good stuff has yet to be merged in from the automount 4 daemon.

The kernel bits are in the linux-2.6-autofsng repository. Broken out patches are forthcoming in the next (weeks?) [I know it is bad practice to pop-up out of nowhere with large changes, but I wasn't able to get anything out much earlier due to a variety of reasons. From now on, expect to see much traffic from me as I feed a broken-out patchsets to the list.]. It has the following major changes to it:

- - changes to the vfsmount tree structures so that you can detach and re-attach sub-trees of the vfsmount tree. The current implementation is admittedly a bit gross and will require work to make it pretty (and to get rid of having to grab a rwlock on every mntget/mntput!).

- - the addition of a mountpoint file descriptor api. I don't care for the interface at the moment, and I'll be posting interface descriptions later on along with broken out patches so that the interface itself can be thought through.

- - vfs native support for expiring mountpoints (and entire subtrees of them). There currently exists a syscall entry to specify this from userspace as a way to easily test it. As well, you can specify expiry information using the above mountpoint file descriptor api.

- - a new module implementing the 'autofs' filesystem called autofsng. This filesystem will support automounting of both direct and indirect maps. It also supports 'browsing'. Most of this magic happens using '->follow_link' walks on directory inodes. This is ugly, but it appears to be the best way to properly handle automounting from within the kernel.

There does remain a good amount of work to do, and I've tried to list things on the top of my head in the autofsng/autofs/TODO file. I'm sure I missed stuff :\

At this point, I can run and pass a ported autofs connectathon testsuite. I'm working on figuring out how to get the testsuite included in the package. For comparison, both autofs3 and autofs4 couldn't handle the majority (>%95) of the tests done. As well, we've uncovered a couple of nfs related issues that we'll be following up with on the nfs list.

So, if you have time to spare and you care about automounting, please have a try at using it. If you are curious enough to wade through it, feel free to give feedback/flames/comments on the code/design/weather.

Stew Smith said, "autofsng userland tarball and kernel patch can now be found here for non-bitkeeper users:"

7. Porting Linux To The Xbox

27 Sep 2004 - 29 Sep 2004 (18 posts) Archive Link: "[Patch] i386: Xbox support"

Topics: Legal Issues, Microsoft

People: Ed SchoutenWill DysonNick PigginDavid WeinehallRahul KarnikPavel MachekLinus TorvaldsAndrew Morton

Ed Schouten said that he'd "Added support for Microsoft Xbox gaming consoles by adding the config option 'CONFIG_X86_XBOX'. This patch is very minimalistic and should give the fellows at a starting point." Nick Piggin asked if anyone would ever want to run a Linux kernel on an xbox; and Will Dyson and Ed said yes indeed they wanted this. As Will put it, "I would appreciate having fewer out of tree patches to apply in order to run a new kernel." Nick replied:

I ask because there is probably quite a large number of embedded type devices devices that you could "just add a small patch for" to get it working. The added fact that you have to "hack" the hardware (I think?) to even get it to run Linux makes it probably a bit more questionable (it is great that we can run on xbox, but maybe not too harmful to keep it as an external patch). Anyway I've otherwise got no objections ;) if you can convince Andrew and/or Linus to merge it, then fine.

Ed replied:

you have multiple options to get Linux on it (flash the BIOS with cromwell, grub-based bootloader, alter some of its current software, etc).

The reason why the Xbox-Linux folks and I think it should belong in the main tree is adoption. Xbox Linux has been around since 2001 if I remember correctly and there are almost no distributions around that really support the Xbox. The people at Debian for example will only add Xbox support if it is available in the main tree.

David Weinehall also said to Nick, "I really hope that small patches for embedded type devices get accepted (given, of course, that they follow the same quality standards as other patches), just like we accept drivers for the x86..." Pavel Machek agreed with this sentiment, saying that the Xbox port was really just another port like ARM etc.

Nick said that the Xbox was a special case because running Linux on it required actually circumventing the hardware. But he reiterated that if Andrew Morton or Linus Torvalds accepted the patch, he'd have no objection. Rahul Karnik replied:

Linus rejected a similar (slightly larger patch) last year.

That said, he does change his mind. Is this still a "politically hot potato"?

Ed said:

From my point of view it isn't. Xbox-Linux already exists for three years and Microsoft still haven't done anything against it. It would be silly if they would file a lawsuit against us, after three years.

If they would, it would be useless anyway. Quote from "Everything done on this project is for the sole purpose of writing interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA."

Sect. 1201 (f) can be read here:







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.