Table Of Contents
|1.||15 Aug 2004 - 28 Aug 2004||(24 posts)||New I2O Maintainer; I2O Code Merging Into -mm|
|2.||23 Aug 2004 - 31 Aug 2004||(53 posts)||Linux 2.6.9-rc1 Released; Some Discussion Of Patch Release Policy|
|3.||25 Aug 2004 - 27 Aug 2004||(6 posts)||Linux 2.4.28-pre2 Released; Status Of Supporting Various GCC Versions|
|4.||26 Aug 2004 - 30 Aug 2004||(39 posts)||Developer Debate Over Maintainership And Binary Driver Hooks; Specifically PWC Driver|
|5.||27 Aug 2004||(2 posts)||Documentation For New x.y.z.n Kernel Bug-Fix Versioning Scheme|
|6.||27 Aug 2004 - 30 Aug 2004||(32 posts)||More On The PWC Driver|
|7.||29 Aug 2004||(1 post)||PowerPC Maintainership|
|8.||30 Aug 2004 - 1 Sep 2004||(27 posts)||Linux 2.6.9-rc1-mm2 Released|
|9.||31 Aug 2004||(2 posts)||Status Of Intel PRO/Wireless Drivers|
|10.||1 Sep 2004||(1 post)||Linux Cluster Infrastructure BOF at Linux Kongress|
Mailing List Stats For This Week
We looked at 2398 posts in 12916K.
There were 529 different contributors. 281 posted more than once. 194 posted last week too.
The top posters of the week were:
1. New I2O Maintainer; I2O Code Merging Into -mm
15 Aug 2004 - 28 Aug 2004 (24 posts) Archive Link: "Merge I2O patches from -mm"
Topics: Disk Arrays: RAID, I2O
People: Warren Togami, Andrew Morton
Warren Togami said:
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.
Andrew Morton said the patches would be merged soon, and agreed that Markus should be the I2O maintainer - though not without his permission. Markus replied, accepting the post, and there followed some technical discussion about the patches.
2. Linux 2.6.9-rc1 Released; Some Discussion Of Patch Release Policy
23 Aug 2004 - 31 Aug 2004 (53 posts) Archive Link: "Linux 2.6.9-rc1"
Topics: I2C, Kernel Release Announcement, Serial ATA, Version Control
People: Linus Torvalds, Matt Mackall
Linus Torvalds announced Linux kernel 2.6.9-rc1, saying:
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 126.96.36.199? 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 188.8.131.52, 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 ;)
Regarding the decision to patch against 2.6.8, Matt Mackall said, "Phew, I was worried about that. Can I get a ruling on how you intend to handle a x.y.z.1 to x.y.z.2 transition? I've got a tool that I'm looking to unbreak. My preference would be for all x.y.z.n patches to be relative to x.y.z." Linus replied, "Hmm.. I have no strong preferences. There _is_ obviously a well-defined ordering from x.y.z.1 -> x.y.z.2 (unlike the -rcX releases that don't have any ordering wrt the bugfixes), so either interdiffs or whole new full diffs are totally "logical". We just have to chose one way or the other, and I don't actually much care." He invited discussion, and although several folks participated, his final decision was left open. The x.y.z.n situation is so rare that it may be some time before we learn what the actual policy will be.
3. Linux 2.4.28-pre2 Released; Status Of Supporting Various GCC Versions
25 Aug 2004 - 27 Aug 2004 (6 posts) Archive Link: "Linux 2.4.28-pre2"
Topics: Disks: IDE, FS: NFS, Hot-Plugging, PCI, Serial ATA
People: Marcelo Tosatti, Adrian Bunk, Willy Tarreau, Ozkan Sezer
Marcelo Tosatti announced Linux kernel 2.4.28-pre2, saying:
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.
Ozkan Sezer pointed out several additional GCC 3.4 fixes, and Adrian Bunk reported additional compile errors when trying to build the kernel with that compiler. He also saw a lot of warnings, but said, "They are not a real problem with gcc 3.4, and whether gcc 3.5 will ever be supported as compiler for kernel 2.4 is a question whose answer lies far in the future." Ozkan said he really wanted to see GCC 3.5 supported, but Willy Tarreau replied, "Tell that to gcc developpers who constantly break compatibility between versions. I even have userland programs which do not compile anymore with gcc-3.3 and which I don't even know how to 'fix' (workaround ?)." And Marcelo said:
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.
4. Developer Debate Over Maintainership And Binary Driver Hooks; Specifically PWC Driver
26 Aug 2004 - 30 Aug 2004 (39 posts) Archive Link: "Termination of the Philips Webcam Driver (pwc)"
Topics: Compression, Philips Webcam Driver, USB
People: Craig Milo Rogers, Linus Torvalds, Alan Cox, Christoph Hellwig
Craig Milo Rogers said:
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.
Christoph Hellwig pointed out that the author had no legal authority to demand the driver be removed. As free software, anyone could step up as maintainer, so long as they adhered to the license. Linus Torvalds replied:
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.
There were various voices of assent and dissent, and at one point Linus also added, "Greg is right - we don't keep hooks that are there purely for binary drivers. If somebody wants a binary driver, it had better be a whole independent thing - and it won't be distributed with the kernel."
Elsewhere in the midst of discussion, Alan Cox disagreed with Linus' assertion that it was appropriate to remove code if the author requested it. Alan said, "Then the author shouldn't have GPL'd it. Its one author who gave irrevocable rights versus tens of thousands of users." Elsewhere, Alan added, "He is not sole author. Large parts of the code are based on other authors work and simply copied from the standard framework. Please put back the version without the hooks. It is useful to all sorts of people in that form. When the author GPL'd it he gave up his rights to remove it. Expecting people to clean-room reverse engineer GPL source is a joke."
Linus replied, saying "I'm disgusted by how many people have been complaining, yet when I ask people to step up and actually _do_ something about it, people suddenly become very quiet, or continue complaining about it ignoring the fundamental issue." He asked point-blank if Alan would be willing to be the maintainer, and Alan said yes, he would. Craig also stepped forward and pointed out that he had offered to be the maintainer as well.
5. Documentation For New x.y.z.n Kernel Bug-Fix Versioning Scheme
27 Aug 2004 (2 posts) Archive Link: "[PATCH] README - Explain new 2.6.xx.x bug-fix release numbering scheme"
People: Daniel Andersen, Maciej Soltysiak
Daniel Andersen said, "This patch explains the new 2.6.xx.x bug-fix release numbering scheme introduced with 184.108.40.206. I hope this can help people understand how to patch such kernels." The patch modified the linux/README file in the source tree, to say:
As of kernel 2.6.8 there was a bug-fix release numbering scheme introduced. In such cases a fourth number is added to the release version, eg. 220.127.116.11. When patching from a 2.6.xx(.x) release to a newer version, patches are to be applied against the original release, eg. 2.6.8 and not the bug-fix release 18.104.22.168. Old patches can be reversed by adding the "-R" option to patch.
Maciej Soltysiak suggested:
How about giving an example like:
To apply a bugfix release patch:
# cd /usr/src/linux-2.6.8
# patch -p1 <../patch-22.214.171.124
To apply a new release on a bugfix tree:
# cd /usr/src/linux-126.96.36.199
# patch -p1 -R <../patch-188.8.131.52
# patch -p1 <../patch-2.6.9
Examples are always good.
6. More On The PWC Driver
27 Aug 2004 - 30 Aug 2004 (32 posts) Archive Link: "Summarizing the PWC driver questions/answers"
Topics: Ottawa Linux Symposium, Philips Webcam Driver
People: Greg KH, Alan Cox, David S. Miller, Andrew Morton
Greg KH said:
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
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
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.
Kenneth Lavrsen replied, as an owner of one of the cameras that would not not work after the removal of the hook. He argued that the hook had been there for years, did not need to be removed, and was the sole point of support for people with the camera in question. David S. Miller pointed out that anyone who wanted could patch the kernel back to its previous state. A lot of other folks pointed out that hooks for binary modules were expressly against kernel policy, and were attempts to get around the GPL.
It seems this debate will be ongoing. At several points Alan Cox threatened to request that all of his kernel contributions over the years be removed, if Linus was going to institute a policy of removing an author's code on request. He felt it was ridiculous because the author had licensed the code for inclusion in the Linux kernel, and could not revoke that license legally, or even just as a question of ethics. The author had no right, according to Alan, to determine whether their GPLed code went in or out of the kernel.
7. PowerPC Maintainership
29 Aug 2004 (1 post) Archive Link: "[PATCH] Update PPC MAINTAINERS & CREDITS"
Topics: CREDITS File, MAINTAINERS File
People: Paul Mackerras, Anton Blanchard
Paul Mackerras posted a patch to the MAINTAINERS file, saying, "David Engebretsen has moved on to other things and is no longer maintaining ppc64. This patch adds an entry in CREDITS to note his contribution in leading the team that did the PPC64 port originally and updates various PPC-related MAINTAINERS entries." The patch removed David Engebretsen as the 64-bit PowerPC maintainer, and listed Paul and Anton Blanchard instead.
8. Linux 2.6.9-rc1-mm2 Released
30 Aug 2004 - 1 Sep 2004 (27 posts) Archive Link: "2.6.9-rc1-mm2"
People: Andrew Morton
Andrew Morton announced Linux 2.6.9-rc1-mm2 (ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc1/2.6.9-rc1-mm2/) , saying, "Nothing particularly noteworthy here. Some seriously bad scheduler performance with SMT and HT was fixed up, as was the fails-to-read-the-last-4k-of-a-file brown bag."
9. Status Of Intel PRO/Wireless Drivers
31 Aug 2004 (2 posts) Archive Link: "[Announce] Update on ipw2100, ipw2200, and support for Intel PRO/Wireless"
People: James Ketrenos, Arjan van de Ven
James Ketrenos said:
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.
Arjan van de Ven was very impressed, and thanked James and the other ipw developers for their good work.
10. Linux Cluster Infrastructure BOF at Linux Kongress
1 Sep 2004 (1 post) Archive Link: "[ANNOUNCE] Linux Cluster Infrastructure BOF at Linux Kongress"
Topics: Ottawa Linux Symposium
People: Daniel Phillips
Daniel Phillips said:
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:
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:
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.
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.
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 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.