This is a request to please merge the I2O patches currently in Andrew Morton's -mm tree into the mainline kernel. They resolve all known reported issues with I2O RAID devices. If they can be included soon, it would be possible to implement and test direct installation before FC3 Test2 freeze.

Also because Markus would never ask himself, I nominate Markus Lidel as the "maintainer" of the 2.6 generic I2O layer. He has put a tremendous amount of work into improving an otherwise neglected part of the kernel. Thanks to his efforts it is today usable and stable on multiple archs and all known supported cards.

tons of patches merged, with me being away for a week, and also the normal pent-up patch demand after any stable kernel. Special thanks as always to Andrew, who synced up 200+ patches (he's attributed in the sign-off lines, but not in the appended shortlog, so I just wanted to point that out).

Changes all over: arm, ppc, sparc, acpi, i2c, usb, fbcon, ntfs, xfs, nfs, cpufreq, agp, sata, network drivers - you name it. Most of the changes are fairly small, but there's a lot of them.

Administrative trivia, and one thing I agonized over: should I make the patches relative to 2.6.8 or 2.6.8.1? I decided that since there is nothing that says that a "basic bug-fix" releases for a previous release might not happen _after_ we've done a -rc release for the next version, I can't sanely do patches against a bugfix release.

Thus the 2.6.9-rc1 patch is against plain 2.6.8. If you have 2.6.8.1, you need to undo the .1 patch, and apply the big one. BK users and tar-balls don't see that particular confusion, of course ;)

Here goes the second -pre of v2.4.28.

It contains more SATA fixes, S390 update, number of PCI hotplug fixes, NFS update, IDE PCI Triflex, amongst others.

Also a bunch of gcc 3.4 fixes, hopefully we are done with that now.

I dont care much about having gcc 3.5 work on v2.4 right now. Right now I think we wont ever care about supporting it.

gcc 3.4 is more a of a concern because there is demand for it - Mikael has been maintaining the patches out-of-the-tree for sometime now and I received quite some reports about them (ie there is pressure for that).

But, due to the v2.4 state of life (bugfix mode only), I've been very annoyed by these patches already. Uninliningfunctions is the most annoying thing to me.

It doesn't make sense for it (v2.4) to work on new-shiny-gcc next generation, v2.6/2.7 are there to support those.

Over on the linux-usb-devel mailing list, a spat has arisin between the Linux 2.6 USB maintainer, Greg K-H, and Nemosoft, the author of the driver (drivers/usb/media/pwc*) for certain Philips-based Web cameras. As a result, Nemosoft has asked that his driver be removed from the Linux 2.6 kernel.

The driver is structured as two modules: an open-source module, included in the standard Linux kernel for years, which controls the basic operations of the camera chip, and a closed-source module, distributed in object format independently of the Linux kernel, that provides decompression services for proprietary codecs that are used for higher-resolution modes in some Web cameras based on this chip family. A hook in the open-source driver allows decompression modules (codec modules) (which may, after all, be either open source or proprietary) to register with the main driver.

Citing the fact that the only current use of the hook was to register a non-open-source module, and citing a policy statement by Linus Torvalds (see the discussion on the linux-usb-devel archive for details), Greg K-H removed the hook from Nemosoft's in-kernel driver, and Nemosoft withdrew his driver from Linux.

As a not uninterested bystander (I just invested $200 of my personal money in Logitech web cameras on the strength of the pwc driver, based on Web research only two days old now!), I appeal for higher-level arbitration in this issue. I, personally, would prefer a pure open-source kernel, and in fact, Nemosoft posted that he has at this time the opportunity to discuss with Philips the possibility of open-sourcing the codecs involved. However, Greg K-H's unilateral decision to excise the pwc codec hook has so infuriated Nemosoft that, unless another maintainer for this driver steps forth, we may be left with no Linux support at all for this popular family of web cameras.

Yes and no. From a legal standpoint you're right. However, we should also be polite. If he's the sole author, and he asks for it, I think it's reasonable to honor his wishes.

Of course if some new maintainer shows up and decides to infer how the device worked by looking at the original open-source code, that's also clearly fine.

I don't want people to play lawyer. Honoring peoples rights to the code they write is more important than just the law.

How about giving an example like:

To apply a bugfix release patch:
# cd /usr/src/linux-2.6.8
# patch -p1 <../patch-2.6.8.1

To apply a new release on a bugfix tree:
# cd /usr/src/linux-2.6.8.1
# patch -p1 -R <../patch-2.6.8.1
# patch -p1 <../patch-2.6.9

Examples are always good.

So, I've gotten a lot of emails about this topic, so I'll just answer them all here in public, and point people at them when they ask them again:

First off, here's Nemosoft's big post about the driver, please read that first, and the responses to that thread: http://thread.gmane.org/gmane.linux.usb.devel/26310

And here's Linus's response after I removed the driver, when Nemosoft asked me to: http://thread.gmane.org/gmane.linux.kernel/229968

Oh, and there's now a lwn.net thread too: http://lwn.net/Articles/99615/

Ok, on to the questions:

Q: Why did you remove the hook from the pwc driver?
A: It was there for the explicit purpose to support a binary only module. That goes against the kernel's documented procedures, so I had to take it out.

Q: That hook had been in there for years! Why did you suddenly decide to remove it now?
A: I was really not aware of the hook, and the fact that it was only good for a binary module to use. I'm sorry, I should have realized this years ago, but I didn't. Recently someone pointed this hook out to me, and the fact that it really didn't belong in there due to the kernel's policy of such hooks. So, once I became aware of it, I had no choice but to remove it.

Q: Why did you delete the whole pwc driver from the tree?
A: That is what the original author (Nemosoft) wanted to happen. It was his request, and I honored it. Go ask him why he wanted it out if you are upset about this, I merely accepted his decision as he was the current maintainer and author of the code.

Q: But you took away my freedom! Isn't Linux about freedom?
A: Again, it was Nemosoft's decision. The kernel also has to abide by it's documented procedures, so that is why the hook had to go. Remember, the original driver was released under the GPL, so you are free to take that code and maintain it if you so desire. I'd gladly support someone taking the GPL code and agreeing to maintain it, and resubmitting it for inclusion in the main kernel tree. That's the freedom that Linux provides, no closed source OS would allow you to do that, if a company pulled support for a product (which happens all the time.)

Q: You jerk, I had invested lots of money in this camera, you are costing me money by ripping it out. You should be ashamed of yourself!
A: See the above question about freedom. If it means that much to you, then offer to maintain the code, it's that simple.

Q: You are keeping companies from wanting to write binary drivers for Linux.
A: Duh! What do you think all of the kernel developers have been stating for years, in public. Binary drivers only take from Linux, they do not give back anything. See Andrew Morton's OLS 2004 keynote address for more information and background on this topic.

Q: You are a fundamentalist turd / jerk / pompous ass / GNU-freebeer-biased-idiot-fundamentalist fucktard / ignorant slut!
A: I've been called worse by better people, get over yourself.

It's been a while since I've updated lkml and netdev on the progress of the ipw projects. Given the recent announcement by Intel for the introduction of Intel PRO/Wireless 2915 ABG Network Connection miniPCI adapter, I thought now was a good time...

First, thanks to everyone that has been contributing, using, testing, and reporting feedback for the projects described below. The support by folks in the community has been terrific -- the drivers wouldn't be anywhere near as feature rich and stable as they are today if not for the contributions of everyone.

The ipw2100 project (802.11b) has progressed very well. We are in the process of cleaning up the driver for submittal to netdev for eventual inclusion into the kernel. The driver currently supports wep, 802.1x, monitor mode, adhoc, infrastructure, etc. Suspend/resume isn't quite functioning yet, but we'll get there soon. This project is hosted at http://ipw2100.sf.net.

The ipw2200 project (802.11bg), which was launched back in May, is quickly catching up to the ipw2100 project in terms of functionality. It currently supports wep and 802.1x in infrastructure mode. Currently it will only associate at B data rates; hooking in the G capabilities is going on right now. We'll then tackle adhoc and remaining feature gaps. We had been planning on holding off submittal for kernel inclusion until we were feature complete. However, several folks have requested that we accelerate that plan and get it in sooner rather than later. To that end we're working to try and get it ready for submittal along with the ipw2100 project. This project is hosted at http://ipw2200.sf.net.

The ipw2100 and ipw2200 projects currently share the 802.11 frame handling stack for Tx/Rx and some management frame processing. That code has been pulled into its own module suite (ieee80211), based on work from the Host AP project. That code needs to be resync'd with the Host AP code (and vice versa where appropriate) so that then all of those drivers will be able to leverage a single wireless network stack.

Anyway, this brings me to announcing Linux support for the Intel PRO/Wireless 2915 ABG Network Connection adapter. As of next week, the ipw2200 project will also begin supporting the ABG adapter. From the driver's perspective, the only change between the two cards is the addition fo the A radio on the 2915. So, adding support for the ABG is just a matter of updating the firmware used by the ipw2200 project, adding PCI id's, and putting in support for A. That work will progress as we continue to bring full support for the ipw2200 project.

At some point in the near future we will rename the ipw2200 project to something more appropriate to identify it as supporting both the 2200 and 2915 adapters.

There will be a Linux Cluster Infrastructure BOF at Linux Kongress in Erlangen, Germany, thursday 2004-09-09 or friday 2004-09-10. The exact day, time and room number to be posted here:

http://www.linux-kongress.org/2004/program.html

This will be round three of the Linux cluster infrastructure community effort. Rounds one and two were at OLS and Minneapolis, respectively. A summary of the latter is available here:

http://sources.redhat.com/cluster/events/summit2004/presentations.html

The story so far: We all agree that the time has come to establish a kernel infrastructure for cluster filesystems, which will also be useable by user space applications. Or at least, most of us agree about that. At Minneapolis we parted on the understanding that we would all read code and find out why (or why not) the GFS kernel support infrastructure can serve the needs of cluster systems beyond GFS, including other cluster filesystems, user space cluster applications, and the Single System Image project.

http://sources.redhat.com/cluster/

Last time, Red Hat engineers outnumbered Suse engineers by roughly ten to one. The Linux Kongress BOF therefore presents an opportunity to redress that imbalance.