Kernel Traffic #279 by Zack Brown

                        Kernel Traffic #279 For 20 Oct 

                                 By Zack Brown

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Mailing List Stats For This Week
  * Threads Covered

    1. 16 Sep  - 23 Sep  (39    Linux 2.6.9-rc2-mm1 Released
                         posts)
    2. 20 Sep  - 26 Sep  (12    Linking Drivers With Modules In SysFS
                         posts)
    3. 20 Sep  - 23 Sep  (27    ipchains And ipfwadm To Be Removed; iptables
                         posts) Replacing Them, But Not Yet Fully Ready
    4. 23 Sep            (1     Staircase Scheduler Version 8.6 Released
                         post)
    5. 24 Sep  - 27 Sep  (38    Linux 2.6.9-rc2-mm3 Released
                         posts)
    6. 24 Sep  - 29 Sep  (3     Autofs NG 0.1 Released
                         posts)
    7. 27 Sep  - 29 Sep  (18    Porting Linux To The Xbox
                         posts)

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:

  * 100 posts in 428K by (janitor)
  * 65 posts in 547K by William Lee Irwin III
  * 47 posts in 217K by Benjamin Herrenschmidt
  * 39 posts in 136K by Alan Cox
  * 29 posts in 317K by Anton Altaparmakov
  * Full Stats

 

1. Linux 2.6.9-rc2-mm1 Released
16 Sep  - 23 Sep  (39 posts) Archive Link: "2.6.9-rc2-mm1"
Topics: Kernel Release Announcement
People: Andrew Morton, Jesse Barnes

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

    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

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  - 26 Sep  (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 Bottomley, Greg KH, Alexander Viro, Greg KH

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  - 23 Sep  (27 posts) Archive Link: "[PATCH] Warn people that ipchains
and ipfwadm are going away."
Topics: Backward Compatibility, Spam, Virtual Memory
People: Rusty Russell, Bill Davidsen, Richard B. Johnson, William Stearns, Andi
Kleen, David Woodhouse, Albert Cahalan, Matthew Garrett, David 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

    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.

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  (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:

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

 

5. Linux 2.6.9-rc2-mm3 Released
24 Sep  - 27 Sep  (38 posts) Archive Link: "2.6.9-rc2-mm3"
Topics: Kernel Release Announcement
People: Andrew Morton, Dmitry Torokhov

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

    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.

 

6. Autofs NG 0.1 Released
24 Sep  - 29 Sep  (3 posts) Archive Link: "[announce] Autofs NG 0.1"
Topics: FS: autofs, Version Control
People: Mike Waychison, Stew Smith

Mike Waychison said:

    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.

Stew Smith said, "autofsng userland tarball and kernel patch can now be found
here for non-bitkeeper users: ftp://ftp-eng.cobalt.com/pub/users/ssmith/
autofsng/"

 

7. Porting Linux To The Xbox
27 Sep  - 29 Sep  (18 posts) Archive Link: "[Patch] i386: Xbox support"
Topics: Legal Issues, Microsoft
People: Ed Schouten, Will Dyson, Nick Piggin, David Weinehall, Rahul Karnik, 
Pavel Machek, Linus Torvalds, Andrew 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 xbox-linux.org 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.

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

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

 

 

 

 

 

 

                       We Hope You Enjoy Kernel Traffic
                                        

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
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License, version 2.0.