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 #281 For 30 Oct 2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1634 posts in 9476K.

There were 454 different contributors. 247 posted more than once. 188 posted last week too.

The top posters of the week were:

1. Linux 2.6.9-rc2-mm2 Released; Various Config Options Break ia64 In Various Kernels

22 Sep 2004 - 8 Oct 2004 (36 posts) Archive Link: "2.6.9-rc2-mm2"

Topics: Big O Notation, FS: ext3, Kernel Release Announcement, Kexec, SMP, Version Control

People: Andrew MortonJesse BarnesTony LuckPeter Williams

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

Responding to this and other kernels booting on ia64, Jesse Barnes said, "Current bk works on my 2p Altix, and iirc 2.6.9-rc2 worked as well. I'm trying 2.6.9-rc2-mm2 right now. I haven't tried generic_defconfig yet either, maybe that's it?" Andrew posted his config file, but Jesse couldn't find anything suspicious in it. Elsewhere, Jesse speculated, "Maybe this is another, more severe instance of the problem James reported last week that was worked around by enabling CONFIG_DISCONTIGMEM." Andrew replied, "It looks like Tony is wearing the BPB." [Brown Paper Bag] "The below patch from September 8 is what causes my non-discontigmem virtual-mem-map ia64 box instantly reboot. Reverting it makes things happy." He also asked a "Process question: how is it possible that the ia64 tree could have been this dead for this long?" Tony Luck replied, "Because we have immense confusion about which combinations of config options (NUMA, DISCONTIG, VIRTUAL_MEM_MAP, SMP) are supported. Kconfig allows almost any combination of them, but on any given week only some combinations work. The patch that broke things for you came in to fix a problem for Peter." He said he'd investigate further.

2. Prototype Of NFS Caching Files Locally Via CacheFS

4 Oct 2004 - 13 Oct 2004 (11 posts) Archive Link: "[PATCH] NFS using CacheFS"

Topics: FS: CacheFS, FS: NFS, Networking, POSIX

People: Steve DicksonTrond Myklebust

Steve Dickson said to Trond Myklebust:

Here here is the first stab at having NFS use the CacheFS that is currently in the -mm tree. As you know CacheFS is a caching filesystem that allows network filesystems, such as AFS and now NFS, to cache data pages on the local disk. This is a big win (especially with read-only filesystems) since it drastically cuts down on the amount of data read across the network. Plus the cached data survives umounts and reboots (since CacheFS journals the data). So when a client comes back up or the filesystem is remounted, all that is needed is a few small getattrs to insure the data is still valid. If it is, NFS reads are turned into local disk reads.... A Huge gain in performance!!!!

I have structured that patch so CacheFS is a mount option. I figured this was the safest way to introduce CacheFS and not completely break NFS.... And if for some reason, NFS is not able to get an initial Cachefs cookie (i.e. it can't use CacheFS) , NFS will dynamically turn off the mount option, disabling the use of the cache..

But as usual there are some issues....

  1. NFS aliasing. The fact that:

    mount hades:/hades /a
    mount hades:/hades/xxx /b

    creates separate super blocks causes problems for CacheFS. With the current -mm code, these type of mount actual causes CacheFS to crash (although I do have a proposed patch that David is looking at).

  2. NFS4 is not supported. I simply have not had time to get this working. But I will!!
  3. There is no user level support. I realize this is extremely cheesy but I noticed that the NFS posix mount option (in the 2.6 kernel) was no longer being used, so I high jacked it. Which means to make NFS to used CacheFS you need to use the posix option:

    mount -o posix server:/export/home /mnt/server/home

PS. The new CacheFS mailing that have been set up is at I encourage you and anybody else interested in this type of technology to subscribe....

Trond replied, regaring using the posix option in mount:

This is my one and only real gripe about it. The posix mount option is clearly documented, so we really cannot play around with it. Why can't you just add a separate cachefs flag?

Otherwise, I'm a bit dubious about the wisdom of putting nfs_invalidatepage() and nfs_releasepage() into fs/nfs/file.c. These are not file operations, but rather pure page cache operations. I would have thought that either read.c or possibly nfs-cachefs.c would be more appropriate.

Please note too that Chuck has made generic functions for copying and comparing NFS filehandles. They should be used in nfs_cache_fh_match() & co. I'm a bit worried about the use of the raw IP address in nfs_cache_server_match(). It seems to me that when we add the NFSv4.1 support for trunking over several different transport mechanisms (RDMA, IPv4/v6 etc) on the same mountpoint, then we may end up with a problem. We can probably leave it in for now, but later we may want to consider switching to using server->hostname or something equivalent.

Otherwise, it looks good. Looking forward to try it out...

Clemens Schwaighofer also liked the idea of a CacheFS flag, and David said that the current behavior was just a convenience for prototyping, that could be done away with later. Steve Dickson confirmed, "it was the easiest way to get things started (i.e. no userlevel changes needed at all).... The 'fscache' flag will be coming along with the nfs4 support, since nfs4 mounting code does not have an open (unused) mounting flag...."

3. Special Serial Flow Control For Some Braille Terminals

4 Oct 2004 - 8 Oct 2004 (21 posts) Archive Link: "[Patch] new serial flow control"

Topics: Braille, Ioctls

People: Samuel Thibault

Samuel Thibault said:

Some Visiobraille braille terminals (TVB) need a peculiar serial flow control:

We tried to implement that in user space, with ioctl(TIOCMBIS) & al, but the responsiveness is too low: RTS is not raised soon enough, and the device aborts transmission.

Here is a patch for 2.4, a 2.6 patch is coming in another mail. It defines a CTVB flag the same way CRTSCTS is defined, letting user space choose whether to use it or not (better ideas for the name are welcome). This makes the device work perfectly (even better than shipped drivers for DOS).

Applying it to vanilla kernel would be a real good thing for people having such costly and useful hardware.

A minute later he posted a 2.6 patch as well.

4. Linux 2.6.9-rc3-mm3 Released

7 Oct 2004 - 8 Oct 2004 (41 posts) Archive Link: "2.6.9-rc3-mm3"

Topics: Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux 2.6.9-rc3-mm3, saying:

5. udev 034 Released; udev Web Page Created

7 Oct 2004 (2 posts) Archive Link: "[ANNOUNCE] udev 034 release"

Topics: FS: devfs, FS: sysfs, Hot-Plugging, Version Control

People: Greg KHKay Sievers

Greg KH said:

I've released the 034 version of udev. It can be found at:

(hm, last announcement I sent out was for 031, sorry about that...)

udev allows users to have a dynamic /dev and provides the ability to have persistent device names. It uses sysfs and /sbin/hotplug and runs entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run. Please see the udev FAQ for any questions about it:

For any udev vs devfs questions anyone might have, please see:

Lots of good bugfixes have happened since the 031 release, and some major enhancements:

Thanks to everyone who has send me patches for this release, a full list of everyone, and their changes is below.

udev development is done in a BitKeeper repository located at:

Daily snapshots of udev from the BitKeeper tree can be found at:
If anyone ever wants a tarball of the current bk tree, just email me.

Half an hour later, he also said:

Ok, I finally broke down and created what has to be the simplest web page ever for udev. It's available at:

Thanks a lot to Kay Sievers for the udev image.

If anyone wants to clean up the page to make it all pretty looking, please feel free to send me an updated version.

6. Some Issues Of Infiniband Patents

8 Oct 2004 - 11 Oct 2004 (20 posts) Archive Link: "InfiniBand incompatible with the Linux kernel?"

Topics: Disks: IDE, Disks: SCSI, Microsoft, PCI, Patents, USB

People: Greg KHEric W. BiedermanJeff GarzikRoland DreierAlan CoxFrancois Romieu

Greg KH said:

Enough people have been asking me about this lately, that I thought I would just bring it up publicly here.

It seems that the Infiniband group (IBTA) has changed their licensing agrement of the basic Infiniband spec. See: for more info about this.

The main point that affects Linux is the fact that now, no non-member of the IBTA can implement any working Infiniband code, otherwise they might run into legal problems. As an anonymous member of a IBTA company told me:

If someone downloads the spec without joining the IBTA, and proceeds to use the spec for an implementation of the IBTA spec, that person (company) runs the risk of being a target of patent infringement claims by IBTA members.

Another person, wanting to remain anonymous stated to me:

In justification for this position people say that they are just trying to get more people to join the IBTA because they need the dues, which by coincidence are $9500 per year, and point out that some other commonly used specs are similarly made available for steep prices. I don't know one way or the other about that but this sounds a lot like the reason that we all gave ourselves for NOT including SDP in the kernel[1].

So, even if a IBTA member company creates a Linux IB implementation, and gets it into the kernel tree, any company who ships such a implementation, who is not a IBTA member, could be the target of any patent infringement claims[2].

So, OpenIB group, how to you plan to address this issue? Do you all have a position as to how you think your code base can be accepted into the main kernel tree given these recent events?

Eric W. Biederman replied:

Greg I see nothing to back up the idea that IBTA intends to go after non-members. I simply see a disclaimer of warranty, and I see wording by your anonymous source that restates a disclaimer of warranty.

Until I see something more to back this up I do not see a problem. In fact I see infiniband prices dropping, and competition increasing. The drivers off of look like they are a good start at making a sane linux implementation.

Even the PCI-SIG requires you to pay for the spec.

I agree it would be suicidally insane for the infiniband trade association to go after a linux stack, as it appears that a large portion of the infiniband users are currently running linux.

Given the vendors I have seen working on hardware and the vendors who are a part of the infiniband trade association there does appear to be a certain amount of disconnect between the two. So this may be an attempt to bring all of the interested parties together.

Jeff Garzik replied:

Well, let's not rely on anonymous sources and go straight to the web site, shall we?

Ordering copies of the spec, for non-members:

Key note: use of spec is only granted for NON-COMMERCIAL use

Now, let's look at the membership agreement for IBTA:

Key note: The point is made repeatedly that there are no patent grants simply by being a member.

Elsewhere, Roland Dreier remarked:

The increase in cost for the spec is rather unfortunate but I think it's orthogonal to any IP issues. Since the Linux kernel contains a lot of code written to specs available only under NDA (and even reverse-engineered code where specs are completely unavailable), I don't think the expense should be an issue.

As for IP, as far as I know, there has been no change to any of the bylaws or other members agreements. If there is some specific provision that concerns you, please bring it to our attention -- the IBTA in general and the IBTA steering committee in general have been very supportive of the OpenIB effort. In fact, most of the IBTA steering commitee companies (Agilent, HP, IBM, InfiniCon, Intel, Mellanox, Sun, Topspin, and Voltaire) have been active participants in OpenIB development. I would hope we can resolve any issues relating to open source and the Linux kernel.

However, I would suspect that we'll find the USB, Firewire, Bluetooth, etc., etc. standards bodies all have very similar IP language in their bylaws and licenses.

Francois Romieu was dismayed to hear that some portions of the Linux kernel were written under NDA restrictions regarding the underlying specs, and felt this dealt a terrible blow to peer review. But Roland replied, "Yes and no. Certainly people without specs can't review spec compliance, but review for coding style, locking bugs, etc. is if anything more valuable."

Greg KH also pointed out to Roland that an agreement had changed: "The "purchase a spec" agreement has changed, right?" To which Roland replied:

Good point. I think the right way to understand this is that the purchase agreement and the $9500 cost is intended to discourage anyone from actually buying the spec -- for the same money you can become a full IBTA member so why shell out for the spec with more restrictions?

This might be counterproductive but I don't think there's anything sinister behind it.

Jeff also pointed out to Roland that the member agreement "-explicitly- does -not- require waiving of patent claims related to any implementation of IB. That's different from ATA, SCSI, USB, the list goes on..." Roland replied:

Fair enough, but read the Bluetooth SIG patent agreement. As far as I can tell, all it requires is that other SIG members receive a patent license. Do we need to do rm -rf net/bluetooth? IEEE only requires that patents be licensed under RAND terms (it does not even require royalty free licensing). Time for rm -rf drivers/ieee1394?

The code that we have written so far is pretty standard driver code, so I have a hard time believing that the IB drivers are any more at risk than any other Linux code. There may be good and valid reasons not to merge IB drivers upstream, but I'd be very disappointed if this FUD about patents is what keeps them out.

Jeff replied, "If there is questionable code, that is _not_ a justification to add more." But Roland said:

my point was not that the bluetooth stack is somehow questionable, but rather that the IP policies of a standards bodies are really not a good reason to keep code out of the kernel. If someone can name one patent that the IB driver stack looks like it might possibly run into, then we would have to take that very seriously. However, no one has done this here -- all we have is FUD or guilt by association or whatever you want to call it.

The mere fact that the IBTA bylaws only require members license their patents under RAND terms shouldn't be an issue. If nothing else, the fact that there are hugely more non-IBTA member companies than member companies who might have patents makes the IBTA bylaws almost a moot point.

For what its worth, I know of at least five companies shipping IB stacks and the only patent licensing that I know of is the Microsoft SDP license, and even that is really just CYA: all Microsoft says is that they _might_ have patents that cover SDP and that they will license them at no cost to anyone who wants them; unfortunately this license is not GPL-compatible, but for proprietary stacks the zero-cost terms look fine. There are people who have looked at Microsoft's patents and concluded that none of them actually apply to SDP as specified by the IBTA.

Alan Cox asked, "The big question seems to be about the standard itself. Are the items at issue hardware or software ? We already deal with a lot of devices that have hardware related patent pools and those by themselves don't seem to cause problems." And Roland said:

As far as I know there are no items at issue. No one has suggested that there actually are any patents to worry about. The big complaint is just that the IBTA member companies haven't made enough promises about their patents.

The OpenIB subversion repository can be checked out by anyone interested. Anyone who wants to can look the code over and look for something patent encumbered.

7. iswraid Going Into 2.4; Device Mapper Subsystem Too Invasive For Inclusion

9 Oct 2004 - 12 Oct 2004 (16 posts) Archive Link: "[Announce] "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3"

Topics: Device Mapper, Disk Arrays: LVM, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, MAINTAINERS File, Serial ATA

People: Martins KrikisAlan CoxMarcelo TosattiJeff GarzikBartlomiej Zolnierkiewicz

Martins Krikis said:

Version of the Intel Sofware RAID driver (iswraid) is now available for the 2.4 series kernels at

It is an ataraid "subdriver" but uses the SCSI subsystem to find the RAID member disks. It depends on the libata library, particularly the ata_piix driver that enables the Serial ATA capabilities in ICH5/ICH6 chipsets. Hence, for kernels older than 2.4.28, the libata patch by Jeff Garzik should be applied before applying this patch. There is more information and some ICH6R related patches at the project's home page at The patch applies cleanly to 2.4.28-pre4 as well, and hopefully can be applied to any 2.4 kernel without too much difficulty.

The changes WRT version 0.1.4 are the following:

Please consider this driver for inclusion in the 2.4 kernel tree.

Driver documentation is included in Documentation/iswraid.txt, which is part of the patch. The license is GPL. I have added myself to the MAINTAINERS list, please feel free to throw me out if you don't think I should have done that.

Please let me know if there is anything else I can do to make this driver acceptable for the 2.4 kernel.

Alan Cox liked seeing this work, remarking, "This seems to make sense to me - for 2.6 we have the DM layer, for 2.4 we've used the ataraid stuff."

But elsewhere, Bartlomiej Zolnierkiewicz asked why the DM layer couldn't be merged into 2.4 instead. A patch already existed, and including the same functionality in 2.4 and 2.6 would ease the upgrade path. Jeff Garzik felt this new subsystem would introduce too great a change into a 'stable' series kernel; but Bartlomiej quoted an email by Marcelo Tosatti, in which Marcelo had said, "New drivers are OK, as long as they dont break existing setups, and if substantial amount of users will benefit from it." Bartlomiej felt both conditions were satisfied, but Jeff remarked that there was a big difference between a driver and a full subsystem. They began arguing the various merits, but Marcelo quickly weighed in with Jeff, saying:

We already have device mapper "like" functionality in v2.4 with RAID/LVM.

I dont think that merging device mapper is an option really, not in my opinion.

It seems the general consensus is to merge iswraid, so I'm fine with it.

8. Linux 2.6.9-rc4 Released

10 Oct 2004 - 12 Oct 2004 (35 posts) Archive Link: "Linux 2.6.9-rc4 - pls test (and no more patches)"

Topics: Kernel Release Announcement, Power Management: ACPI

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.9-rc4, saying:

trying to make ready for the real 2.6.9 in a week or so, so please give this a beating, and if you have pending patches, please hold on to them for a bit longer, until after the 2.6.9 release. It would be good to have a 2.6.9 that doesn't need a dot-release immediately ;)

The appended shortlog gives a pretty good idea of what has been going on. Mostly small stuff, with some architecture updates and an ACPI update thrown in for good measure.

(The ACPI update fixes broken AML with implied returns, and in particular the Compaq Evo notebook fan control. Yay! Guess who has one..)







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.