Kernel Traffic #276 by Zack Brown
[email protected] Sat, 09 Oct 2004 10:25:47 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #276 For 9 Oct
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 15 Aug - 28 Aug (24 New I2O Maintainer; I2O Code Merging Into -mm
posts)
2. 23 Aug - 31 Aug (53 Linux 2.6.9-rc1 Released; Some Discussion Of
posts) Patch Release Policy
3. 25 Aug - 27 Aug (6 Linux 2.4.28-pre2 Released; Status Of
posts) Supporting Various GCC Versions
4. 26 Aug - 30 Aug (39 Developer Debate Over Maintainership And
posts) Binary Driver Hooks; Specifically PWC Driver
5. 27 Aug (2 Documentation For New x.y.z.n Kernel Bug-Fix
posts) Versioning Scheme
6. 27 Aug - 30 Aug (32 More On The PWC Driver
posts)
7. 29 Aug (1 PowerPC Maintainership
post)
8. 30 Aug - 1 Sep (27 Linux 2.6.9-rc1-mm2 Released
posts)
9. 31 Aug (2 Status Of Intel PRO/Wireless Drivers
posts)
10. 1 Sep (1 Linux Cluster Infrastructure BOF at Linux
post) 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:
* 192 posts in 789K by Lee Revell
* 149 posts in 624K by Ingo Molnar
* 78 posts in 402K by William Lee Irwin III
* 59 posts in 505K by Gene Heskett
* 53 posts in 190K by Alan Cox
* Full Stats
1. New I2O Maintainer; I2O Code Merging Into -mm
15 Aug - 28 Aug (24 posts) Archive Link: "Merge I2O patches from -mm"
Topics: Disk Arrays: RAID
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 - 31 Aug (53 posts) Archive Link: "Linux 2.6.9-rc1"
Topics: I2C, Kernel Release Announcement, Serial ATA
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 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 ;)
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 - 27 Aug (6 posts) Archive Link: "Linux 2.4.28-pre2"
Topics: Disks: IDE, FS: NFS, Hot-Plugging, Serial ATA
People: Marcelo Tosatti, Adrian Bunk, Willy Tarreau
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 - 30 Aug (39 posts) Archive Link: "Termination of the Philips Webcam
Driver (pwc)"
Topics: Compression, 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 (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 2.6.8.1. 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. 2.6.8.1.
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 2.6.8.1. 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-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.
6. More On The PWC Driver
27 Aug - 30 Aug (32 posts) Archive Link: "Summarizing the PWC driver
questions/answers"
Topics: Ottawa Linux Symposium
People: Greg KH , Alan Cox, David S. Miller, Andrew Morton, Greg KH
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 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.
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 (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 - 1 Sep (27 posts) Archive Link: "2.6.9-rc1-mm2"
Topics: Hyperthreading
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 (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 (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:
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.
We Hope You Enjoy Kernel Traffic
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.