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

• Added Bart's bk-ide-dev tree to the -mm external tree lineup.

• Added Peter Williams' Single Priority Array (SPA) O(1) CPU Scheduler, aka the "zaphod" cpu scheduler.

  It has a number of tunables and lots of documentation - see the changelog entry in zaphod-scheduler.patch for details.

• This kernel doesn't work on ia64 (instant reboot). But neither does 2.6.9-rc2, nor current Linus -bk. Is it just me?

• Added the kexec-based crashdump code. This is the code which uses kexec to jump into a new mini-kernel when the main kernel crashes. Userspace code in that mini-kernel then dumps the main kernel's memory to disk. These new patches provide the bits and pieces which the mini-kernel needs to be able to get at the main kernel's memory.

  There seem to be no hints as to how to get all this working - that will come.

• Found (and fixed) the bug which was causing those ext3-goes-readonly-under-load problems. It was in the new wait/wakeup code.

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 http://www.redhat.com/mailman/listinfo/linux-cachefs I encourage you and anybody else interested in this type of technology to subscribe....

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

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

• There is no flow control for the PC -> device way (yes, oddly enough)
• For the device -> PC way,
• RTS must be kept low, the device keeps CTS low as well.
• when the device wants to send data, it raises CTS. RTS must be raised as well. Data can then pass, CTS and RTS are lowered.

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.

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

• The zaphod scheduler was dropped - we have some performance-related changes here which need testing.
• Various fixes, updated patches, etc.
• sparc64 and ppc64 successfully compile again.

I've released the 034 version of udev. It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-034.tar.gz

(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: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

For any udev vs devfs questions anyone might have, please see: kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

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

• SELinux support is back in, thanks to Red Hat.
• a new helper program, wait_for_sysfs, is installed as the first program in the hotplug chain. If this program spits out any log messages, please forward them to the email address it tells you to, and we will fix the code.
• scsi_id is updated to the latest version
• volume_id now builds on Gentoo based systems.

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:
bk://linuxusb.bkbits.net/udev

Daily snapshots of udev from the BitKeeper tree can be found at: http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.

Ok, I finally broke down and created what has to be the simplest web page ever for udev. It's available at: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html

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.

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: http://www.theinquirer.net/?article=18922 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?

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

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: http://www.infinibandta.org/specs/How_to_Order_IBTA_Specifications.pdf

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

Now, let's look at the membership agreement for IBTA: http://www.infinibandta.org/meminfo/mem-agreement.pdf

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

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.

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.

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.

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.

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.

Version 0.1.4.3 of the Intel Sofware RAID driver (iswraid) is now available for the 2.4 series kernels at http://prdownloads.sourceforge.net/iswraid/2.4.28-pre3-iswraid.patch.gz?download

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 http://iswraid.sourceforge.net/. 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:

• Different buffer_head b_state bit used for IOs submitted to the mirror.
• Disk sizing problem for disks with odd number of sectors fixed.
• Entering degraded mode with many outstanding IOs fixed.

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.

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.

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