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 #221 For 30 Jun 2003

By Zack Brown

Table Of Contents


Mailing List Stats For This Week

We looked at 1989 posts in 10748K.

There were 575 different contributors. 308 posted more than once. 213 posted last week too.

The top posters of the week were:

1. Status Of ACPI In 2.4

9 Jun 2003 - 18 Jun 2003 (24 posts) Archive Link: "2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken"

Topics: Power Management: ACPI, Virtual Memory

People: Andrew GroverAlan CoxMarcelo TosattiStephan von KrawczynskiTorben Mathiasen

In the course of discussion, Marcelo Tosatti said he'd like to merge the large ACPI patches into 2.4.23 instead of 2.4.22 as others wanted. He said he wanted to put 2.4.22 out very quickly (within a couple months), and that wouldn't give enough time to properly test the ACPI changes. Andrew Grover replied:

I wouldn't have a problem with this, except that you've been deferring the ACPI merge for over a year. We've been maintaining this patch outside the mainline tree for EIGHTEEN MONTHS. Please stop leading me along. Will you EVER merge it?

I am confident it will merge cleanly.
I am confident it will cause no problems when CONFIG_ACPI=off.
I am confident the total number of working machines will go up.
I am willing to bet $500 of MY OWN MONEY on this.

Talk to me, man. What would make you happy? A lot is riding on this.

Marcelo assured him that it would go into 2.4.23-pre, and promised that 2.4.22 would be out quickly enough that it wouldn't constitute a major delay. Alan Cox remarked:

Its been in 2.4.21-ac for a while. I have exactly zero reports of it causing problems in the acpi=n case, and a whole raft of "the first Linux that runs on my toshiba/compaq/hp laptop"

Works well enough for me to have faith in it now.

Stephan von Krawczynski confirmed this with his own experiences, and Torben Mathiasen added that ACPI was needed in order to avoid bad overheating on his laptop.

Elsewhere, Eric Valette challenged Marcelo's sincerity. He said Marcelo had promised to merge ACPI in 2.4.22-pre, and hadn't, and was now promising to merge it in 2.4.23-pre. Eric reiterated the importance people placed on ACPI for the 2.4 kernel; and pointed out that Marcelo had not yet clarified what he was planning for 2.4.22, that would preclude adding ACPI. Marcelo replied (note the turnaround on ACPI):

My plan for 2.4.22 is:

Those are the most important things that are needed now, I think.

2. Linux 2.5.71 Released

14 Jun 2003 - 19 Jun 2003 (34 posts) Archive Link: "Linux 2.5.71"

Topics: Version Control

People: Linus TorvaldsStephen Hemminger

Linus Torvalds announced 2.5.71, and said:

I think I'll call this kernel the "sticky turtle", in honor of that historic "greased weasel" kernel, and as a comment on how sadly dependent I've become on the daily BK snapshots. It's been too long since 2.5.70.

I'll do better, I promise. While most developers happily use either the daily snapshots or the BK tree itself, not everybody does, and a lot of users want "real releases".

There's nothing hugely interesting here, but Al Viro ha sbeen cleaning up the tty layer, and Stephen Hemminger has been fixing up some network device alloc/free issues with the help of various people.

And obviously there are the normal usb/pcmcia/sound/architecture updates. With driver models and networking thrown in as a bonus.

3. Linux 2.5.72 Released; Linus Moves To OSDL

16 Jun 2003 - 18 Jun 2003 (10 posts) Archive Link: "Linux v2.5.72 and a move to OSDL"

Topics: FS: NFS

People: Linus TorvaldsMiles BaderJohn Levon

Linus Torvalds announced 2.5.72, and said:

Ok, I waited too long for 2.5.71, so here's a more timely 2.5.72 release.

It's extra timely largely because the hash list poisoning found some problems in the RPC code, making NFS break. Trond found and fixed the breakage, so 2.5.72 should work fine in an NFS environment too. Let's see if the list poisoning shows any other dodgy list users. Knock wood.

Also, Arnaldo has cleaned up a lot of the networking code to use the generic hash lists, instead of the old ad-hoc net-specific list walking code. That code has been tested pretty well, but please holler if you see something.

Changelog for other details appended.

The other big news - well, for me personally, anyway - is that I've decided to take a leave-of-absense after 6+ years at Transmeta to actually work full-time on the kernel.

Transmeta has always been very good at letting me spend even an inordinate amount of time on Linux, but as a result I've been feeling a little guilty at just how little "real work" I got done lately. To fix that, I'll instead be working at OSDL, finally actually doing Linux as my main job.

[ I do not expect a huge amount of change as a result, testament to just /how/ freely Transmeta has let me do Linux work. My email address will change to "" effective July 1st, but everybody is trying to make the transfer as smooth as possible, so we'll make sure that there will be sufficient address overlap etc to not cause any problems ]

OSDL and Transmeta will have a joint official (read: "boring". You should have seen the bio - that didn't make it - that I suggested for myself for it ;) press-release about this tomorrow morning, but I just wanted to say thanks to Transmeta. It has been a special place to work for, and hello to OSDL that I hope will be the same.

Snif. I'm actually all teary-eyed.

Miles Bader said, "I'm still always a bit amazed when reminded that Linus -- up to now -- _wasn't_ working full time on the kernel. [It's like those guys that bike 100 miles before breakfast, and still make it in to work before me...]"

Elsewhere, under the Subject: [PATCH] OProfile: IO-APIC fixup, John Levon asked if Linus' new email address was working yet, and Linus replied, "It should work, and you might as well start testing it. I still have my mail sending side set up for transmeta, so you'd get replies through the old address, but the more testing the merrier.."

4. Status Of VFS Automount Support

17 Jun 2003 - 24 Jun 2003 (26 posts) Archive Link: "[PATCH] VFS autmounter support"

People: David HowellsAlexander ViroLinus Torvalds

David Howells announced:

The attached patch adds automounting support and mountpount expiry support to the VFS.

This patch involves the adding the following features:

  1. A new dentry operation that (a) marks a dentry as being an automount point, and (b) gets called by the VFS to come up with a vfsmount structure which the VFS then stitches into the mount tree fabric at the appropriate place.
  2. A new lookup flag that is used by sys_*stat() to prevent automounting of the path endpoint. This means "ls -l" in an automounter directory doesn't cause a mount storm, but will display all the mountpoints in that directory as subdirectories (either the underlying mountpoint dir or the root dir of the mounted fs if the mountpoint has been triggered already).
  3. do_kern_mount() is now exported.
  4. The vfsmount structure has acquired, amongst other things, a timeout field. If mntput() notices a vfsmount reach a usage count of 1, then the vfsmount expiry time is set and the namespace that contains the vfsmount has its expiration work chitty queued.
  5. The namespace structure has acquired a work struct that is used to actually perform vfsmount expiry under process context.

Linus Torvalds said he didn't hate it, but wanted to hear from Alexander Viro and others before letting it in. Alexander said:

I'm not too happy with it. If nothing else, IMO it's the wrong way to solve the problem - if you want a bunch of filesystems look like a single object (i.e. go together wherever we mount it, etc.), make it a filesystem. That would make a lot of sense, and not only for AFS.

We need a light-weight automount. No arguments here. But it should be per-namespace - i.e. "I want to have <foo> mounted on /usr/barf on demand and I have no intention to screw somebody else - somebody who might have the same directory seen as /usr/local/debian/barf and want <blah> mounted on demand there".

Namespace is controled by owner of that namespace. It is a security boundary, among other things. And events in one namespace should not cause mounts in another. Yes, AFS wants an illusion of single filesystem composed in fixed way from many pieces. But if you want to do that, do it right - make sure that it acts as a single chunk in mount tree. IOW, make it look like a single filesystem.

David disagreed with Alexander's assessment, but they were not able to resolve the issues within the thread.

Elsewhere, under the Subject: [PATCH] VFS autmounter support v2, David said:

I've revised my patch to make sure a process in one namespace doesn't change the topology of another namespace (kern_automount() will return an error in that case, as does (u)mount). As a bonus, check_mnt() has been simplified to take account of the namespace pointer now in vfsmount.

I've also fixes it so that if an automounted subtree is touched with "mount --bind" or "mount --move", then the base of that tree has its expiry timeout cleared, thus making it a permanent fixture (until manually unmounted).

But Alexander said:

You _still_ don't get it. OK, the last time: kern_automount() will always do the same thing, no matter which namespace we are it. It might be OK for AFS, but it's definitely unfit for any other use.

No amount of "use of (u)mount to rearrange topology" will help here - with your code you have dentry marked, and stepping on it (in any namespace, in any instance of that fs in a namespace) will always do the same thing. And that is Wrong(tm).

David disagreed again, saying, "I think it should do the same thing (but with results limited to the namespace of whatever triggered the automount) until the administrator discards that portion of the tree (umount -l will work there). But I don't think I'm going to get anywhere arguing about it with you." But again, they were unable to agree during the thread.

Elsewhere, under the Subject: [PATCH] VFS autmounter support v3, David said:

Okay, it turns out I don't really need a special operation to deal with automount points... as HPA was pointing out, the same can be done by giving a directory a follow_link() operation...

However, would you consent to accept this patch (or something similar)? It has the actual automounting stuff stuff taken out, leaving two parts:

  1. A convenience function (__do_add_mount) that a module can call to insert a vfsmount into the mount topology at a point described by a struct nameidata (as would be passed to follow_link).

    This can be taken out if you insist on my bouncing the mount parameters down to userspace so that it can issue a mount - provided something approximating fmount() is also provided so that inter-namespace mounting can be done under controlled circumstances.

  2. Automatic mount point expiry. This allows any mountpoint to be given a timeout, such that when mntput() detects that the vfsmount is only used by its parent, a work chitty will be enqueued to cause the containing namespace to be vacuumed later for dead mounts.

I'd also like to make it so that any mount can be given a "timeout" argument, but I'm not sure what the best way to do so is.

Alexander found his approach "broken", and the thread ended.

5. kexec For 2.5.72 Released

17 Jun 2003 - 23 Jun 2003 (3 posts) Archive Link: "[KEXEC][ANNOUNCE] kexec for 2.5.72 available"

Topics: Framebuffer, Kexec

People: Andy Pfiffer

Andy Pfiffer announced:

A patch set for kexec for 2.5.72 is now available. This patch set is based upon the stable 2.5.{67,68,69,70,71} versions.

This patch was tested to work (not counting a VESA framebuffer initialization problem after kexec-ing a new kernel) on a dual-proc P4-1.7GHz Xeon system.

More info here:

Unified full kexec patch for 2.5.72 is here:

Not that anyone cares, but a unified full patch for 2.5.71 is here:

Unstable 2.5.69 kexec patches from Eric Biederman are available here:

Later he said:

A patch for kexec in 2.5.72-mm1 is now available. This patch is based upon the stable 2.5.72 version.

This patch has been lightly tested to work on a dual-proc P4-1.7GHz Xeon system. If you try it, and you use the VESA framebuffer, expect darkness on your screen during the reboot. ;^)

More info here:

The patch:

Source for the matching user-mode tool:

Elsewhere, under the Subject: [KEXEC][ANNOUNCE] kexec for 2.5.73 available, Andy said:

A patch set for kexec for 2.5.73 is now available. This patch set is based upon the stable 2.5.{67,68,69,70,71,72} versions.

This patch was tested to work on a dual P4-1.7GHz Xeon system, a uniprocessor P3-800 system, and a dual P3-866 system. I continue to observe strangeness with the re-initialization of the VESA framebuffer (character-based console TTY worked correctly), a kernel oops in the 2.5.72 version on a 4-way while preparing the reboot memory buffer, and a hang seen when using the serial console (RS232).

More info here:

Unified full kexec patch for 2.5.73 is here:

Source tarball of the matching user-mode utility for kexec 2.5.73:

Unstable 2.5.69 kexec patches from Eric Biederman are available here:

6. Patch Submission Policy

18 Jun 2003 - 19 Jun 2003 (7 posts) Archive Link: "DVB updates, 3rd try"

Topics: Digital Video Broadcasting, Version Control

People: Linus TorvaldsMichael HunoldJohn LevonGreg KH

Michael Hunold asked Linus Torvalds to pull the latest DVB patches from Michael's BitKeeper tree, and Linus replied:

I don't go out to fetch patches, I really want to see them come to me (and even then preferably through a few people acting as quality control and maintainership).

And if there is no clear maintainership relationship and you need to send them directly to me, I really want plain-text patches (they can be big if needed), with:


John Levon posted a script he'd hacked from Greg KH, to help follow Linus' guidelines.

7. MegaRAID Driver Update

20 Jun 2003 (1 post) Archive Link: "[ANNOUNCE]: megaraid 1.18i driver"

Topics: Disk Arrays: RAID

People: MukkerAtul Mukker

Atul Mukker announced:

1.18 series of the driver has been upgraded to 1.18i. This driver has fixes for management applications not working with stock 1.18f driver. Other changes are: Kernel would panic if 2.00.x megaraid driver is loaded on top of 1.18h or previous drivers. This was because of a bug in older drivers which were not reserving the controller's memory region.

This driver also incorporates the important changes made 1.18g and 1.18h driver for firmware handshake. The driver and the patch for 1.18f driver can be downloaded at:

8. More On Possible GPL Violations By Wireless Vendors

24 Jun 2003 - 25 Jun 2003 (14 posts) Archive Link: "GPL violations by wireless manufacturers"

People: Richard Ten Brink

Continuing from Issue #219, Section #16  (7 Jun 2003: Possible GPL Violations By Many Wireless Vendors) , Richard Ten Brink said:

I have had some luck resolving the GPL violation by wireless manufacturers issue. I have sent letters regarding the issue to Linksys, Belkin and Buffalo. This is the letter I received from Buffalo Technologies and below that is the letter I sent to the three manufacturers:

Hi Sir,

We are aware of these requirements and we have the PDF document (attached) and a statement/notice that will be put onto the website within 48 hours for this product. Please let me know if you require further assistance or if you would like to talk further.

This product uses software of GPL/LGPL.
You have the right to acquire source code, change it, and re- distribute it.
The warranty on the product is only applicable if the original or an official Buffalo firmware is on the unit.
Please refer to GNU_LICENSE.PDF.
We don?t have any obligation to pay if a user has to pay to distribute or change the source code.

Thanks for your time.

Craig Reid
Technical Sales Engineer


Dear sirs,

Hereby I would like to inform you that the software on at least one of your products is offered in violation of the General Public License (GPL) as published by the GNU Software Foundation. This may not be known to you due to inclusion of acquired or licensed technology from third-party manufacturers in your product.

The affected product is the Buffalo (Melco) WBR-G54 Wireless Access Point

The infringement of the GPL consists of the following:

Your product makes use of Linux kernel version 2.4.5 and Busybox software, which are both licensed under GPL terms and conditions. The GPL allows copying and distribution of licensed software, provided that the complete corresponding machine-readable source code or a written offer to a complete machine-readable copy of the corresponding source code accompanies the product. As you have fulfilled neither of these obligations, you are in violation GPL terms and conditions.

Your product includes a kernel driver module that is inserted into the GPL licensed Linux kernel when the product is turned on. There is no possible way for the user to prevent the insertion of this module into the kernel. It is also impossible for the user to remove the kernel module from the running kernel. The operation of the included software on your product depends on the operation of the kernel module. For these reasons the kernel driver module is not offered as a separate work as described in Section II of the GPL and must therefore be distributed under the terms and conditions of the GPL. As you have not included the complete corresponding machine- readable source code or a written offer to a complete machine- readable copy of the corresponding source code you are clearly in violation of GPL terms and conditions.

Because of the huge liability your company could be facing I advise you to take appropriate measures to cease offering your product in violation of the GPL.

With Regards,

Richard Ten Brink







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.