Kernel Traffic #279 For 20 Oct 2004

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm1/

• Added lots of Ingo's low-latency patches
• Lockmeter doesn't compile. Don't enable CONFIG_LOCKMETER.
• Several architecture updates

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.

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.

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.

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...

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.

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

http://www.stearns.org/i2i/ipchains2iptables
http://www.stearns.org/i2i/ipchains2iptables.README

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.

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:

http://ck.kolivas.org/patches/2.6/2.6.9/2.6.9-rc2-mm2/

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm3/

• This is a quick not-very-well-tested release - it can't be worse than 2.6.9-rc2-mm2, which had a few networking problems.
• Added Dmitry Torokhov's input system tree to the -mm bk tree lineup.

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

http://marc.theaimsgroup.com/?l=linux-kernel&m=107341940326348&w=2

Anyhow, I've gotten to the point where I have code that people can play with. I've posted it all at http://autofsng.bkbits.net

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.

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.

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.

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

http://marc.theaimsgroup.com/?t=105819036500001&r=1&w=2

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

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 xbox-linux.org: "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: http://cyber.law.harvard.edu/openlaw/DVD/1201.html#f