Awhile ago, I tried to include links from each issue's Table Of Contents to the XML source for that issue, but it turned out the XML was too non-compliant. Hopefully all that has been fixed, and you should find working links to the XML sources of each issue (including translations). Many thanks to the authors and translators of the various Cousins for helping bring the sources into compliance.
BTW, I'd like to draw your attention to Consensus At Lawyerpoint, a page put up by the Electronic Frontier Foundation. Apparently various large media corporations are spending millions of dollars each month, in order to get laws passed that would, among other things, prevent free software drivers for tuner cards for digital TV. This is a very complex issue, but something that is very important for people at large to understand and fight. For more information, read this summary and contact Seth David Schoen at the EFF.
Robin Johnson posted a script, and said, I
have written a script to build incremental patches, as found on bzimage.org
previously. I have written this so that other people will find it easier to
roll their own incremental patches to use.
Adrian Bunk gave a link to
Tim Waugh's patchutils
that contained 'interdiff', that makes incremental
diffs between patches. And interdiff doesn't need the source the patches
are against.
Robin replied that he'd tried 'interdiff' already,
and found that it wouldn't generate correct output. Tim Waugh replied,
I think that the problems Robin was seeing are
resolved in patchutils-0.2.12. (The output was correct, but needlessly
lengthy.)
Greg KH posted some BitKeeper changesets and announced, These changesets add USB device support to the kernel. It is the
Lineo code cleaned up a bit and dropped into the drivers/usb/device/
directory. Over time, the code will migrate into other usb directories
as the core of the device and host code merge together. This release
provides a version that builds properly, and provides a good base
for people to start working with.
He also gave a link to a regular
patch containing the same changes. Greg also added, Thanks to Stuart Lynne from Lineo for releasing this code and working
to have it included in the tree.
And Stuart Lynne replied, Thanks belong to Lineo for working with the customers to
get this released as GPL and Tim Bird for letting me put up the official
release so people wouldn't have to dig it out of the Sharp Zaurus kernel
source.
A few hours after his initial announcement, Greg posted an update (and patch),
which removes the arm sa1100 code from the last series,
as the USB driver in the ARM tree should be used, instead of the previous
old version. I will work with the ARM people to merge that into this portion
of the tree.
Linus Torvalds replied:
Since I haven't pulled any of the usb device updates yet, might I suggest:
- redoing the BK archive completely without the broken series (ie an actual "bk undo")
- explaining to me what a "usb device" is, that isn't a normal USB device? Why is "usb/device/xxx" different from the existing USB device drivers?
In other words, please explain what the _point_ of this code is? Especially since the code is obvious crap, from the little I looked at it, and quite frankly my immediate reaction is that it shouldn't get even _close_ to the kernel before it has gone through some _major_ cleanup.
Let's face it, look at the absolute SHIT in usbd-debug.c, where somebody has re-created strcmp/strcpy/etc, except with stupid names, and bad implementation.
In short, I refuse to pull this crap. The people who wrote it were either on drugs, incompetent, or just plain crazy. "Just say no".
Greg explained, It's code to be a USB client device,
not a USB host device, which is what we currently have. It is used in
embedded devices that run Linux
. Linus replied, saying he might have
been too hasty in outright condemning the patch (which he said he hadn't
fully read). He added:
Ahhh.. A dim light goes on.
It would have made more sense (I think) to call it "usb/client" instead of "usb/device", but maybe that's just because I didn't understand what the thing was all about.
(Ask Davem some day about my irrational hang-ups about naming, and how I sometimes like the same code if it's just named differently ;)
Greg replied, We (the linux-usb-devel list) talked
about different names for this stuff, and tried to follow the naming
convention used in the USB spec. However 99% of kernel developers will
never read that spec, and 100% of users never will, and the name "devices"
failed to convey any good meaning to the first person that saw the tree
outside of the USB developers, so changing the name to "client" makes a lot
more sense :)
Linus replied:
Note that the relevance of the USB spec to most people is exactly 0%.
"USB device" is what people say about the things you call "clients". The real world takes precedence, and there is absolutely _no_ way a Linux "USB device driver" will ever mean that the driver turns the box into a USB device.
A "USB device driver" is driver for the mouse/scanner/whatever, ie the _other_ end, and that's that. Claiming anything else is just confusing and silly.
Since we're talking about the other end of a "host" driver, "client" makes sense - in computers, I've always seen "client" as the reverse of the "host", but maybe that's just me. Outside of computers, "guest" seems to be the proper antonym, but that just strikes me as bizarre (a "USB guest driver"?)
What were the other suggestions?
Several folks suggested that not adhering to terminology used in the USB standard would ultimately be more confusing to anyone working on the code, although no one claimed that non-USB folks would be able to make sense of that terminology without looking at the spec.
At one point, Larry McVoy suggested, What about
"target"? In SCSI land, it's clear that a target is the device, and when you
talk about code that runs on a computer and makes it be a SCSI target, everyone
knows what you mean, right? So what about code that makes a computer a USB
target? Would that work? That's the only thing I could think of that was
similar. Does USB already use the term target for something else?
Linus
replied:
Well, it sounds unambiguous at least to me, and "makes sense".
Which still leaves the actual code implementation cleanliness issues, of course (modulo the USB documentation specifying that "target" means a small USB-controlled fish, thereby confusing all the USB developers).
Greg said 'target' worked for him, and added regarding the cleanliness
issues, I am working on this right now. This will take
a bit longer than just renaming the directory and changing the documentation
:)
Chris Abbey asked, Back in February someone else
asked about support for Promise's cards, and Alan mentioned that it would
probably merge in around the 2.4.19 timeframe. I'm curious what level of
support folks are expecting? Just basic IDE, or support for the hardware
raid features? I'm getting a bit sick of rebooting to a back level kernel
inorder to pull data from their raid, and even more sick of the hard locks
that only occur when I have their binary module inserted. (please avoid
the flame wars about how dirty a binary only module is, I'm well aware
of that, but I live in the real world and have a lot of data one of their
controllers. :( )
Alan Cox asked what Chris meant by support for the
hardware RAID features. He said, AFAIK their only cards
with hardware raid features are the supertrak 100 and SX6000.
Chris
replied, The FastTraK 100 TX2 has hardware raid
(stripe/mirror) support, they have a binary only driver (scsi/ft.o) which
presents this array as a scsi device... this is the level of function I was
hoping was being integrated.
He added, The
current 2.4.18 code recognizes the card and provides vanilla IDE access to
the drives, unfortunately that isn't much use unless someone wants to try and
RE their block allocation on the disks... a decidedly non-trivial endeavour I
can assure you. ;(
Arjan van de Ven and others pointed out that this
was not hardware RAID but software RAID. And Chris remarked, Ya know, I was seriously doubting that this thing was really hardware
raid, why else would they not want to release their driver? ;)
Robert Love posted a patch and announced:
Following patch implements the 2.5 task affinity syscalls on top of the 2.4 O(1) scheduler patches I recently posted. We can implement these now since 2.4's O(1) scheduler now has the migration_thread. Previously, the 2.4 patches I did only worked on the "stock" scheduler.
I have a request for comments:
The locking is no good in this patch. set_cpus_allowed is not atomic and it is certainly not safe to hold a spinlock across a call to it. However, before we call set_cpus_allowed we need a valid reference to the task and assurance the task won't slip away out from under us.
So you say "ah grab tasklist_lock" but we can't hold it across set_cpus_allowed. In 2.5, we solve this by bumping the task_struct's usage count via get_task_struct - this assures us at least the task_struct will not go anywhere until we put_task_struct. We have no such luxury in 2.4...
Mike Kravetz took a look at the patch, and found an area that would seem to allow a process to migrate unexpectedly to a different CPU. There seemed to be nothing stopping such a migration. Ingo Molnar explained:
the migration thread makes sure that the migrated thread will *not* run on that particular CPU. The only issue the migration thread is for is to 'push' the migrated thread from its current CPU.
so we first set the cpus_allowed mask, then we schedule the migration thread (which is a highest RT priority thread) if the thread is running on an invalid CPU.
load_balance() moving a process to another CPU is in fact makes this job easier, and causes no problems. It will pull a process only to allowed runqueues.
this way it can be guaranteed that after the set_cpus_allowed() call the thread is not running on an invalid CPU.
the affinity setting syscalls added by Robert's patch utilize this underlying mechanizm, but kernel threads call it directly as well. Eg. in the softirqd case it's of importance whether the thread is running on the right CPU or not, after calling set_cpus_allowed().
This made sense to Mike, and Ingo added, all
additional eyeballs are welcome :) The only volatile portion of the migration
concept is the initialization (when there is no migration mechanizm yet to
migrate the migration helper threads ... catch-22), the actual migration
part is much more robust than any previous attempt. (and we had a fair
number of approaches in the O(1) scheduler which were all pretty intrusive
and unrobust.)
End of thread.
James Simmons announced, I just finished
sending up the last large change I like to send to Linus for the
framebuffer changes. Since I can't test all the possible hardware there
I like to ask people to test the BK tree out. Once I have positive
reports I like to merge it with Linus BK tree. Thank you.
He
gave a link to his BitKeeper
Tree, but Jes Sorensen complained, If
you want people to test out the patches, posting a bitkeeper only
URL is totally unreasonable! This is exactly what caused the long
flame on linux-kernel the other day ;-(
. James posted a standard
diff against 2.5.9 and asked people to test it out.