Kernel Traffic #164 For 28�Apr�2002

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.

There were 345 different contributors. 171 posted more than once. 121 posted last week too.

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 :)"

19�Apr�2002�-�23�Apr�2002 (10 posts) Archive Link: "PDC20268 TX2 support?"

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? ;)"

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

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.

�
Kernel Traffic Latest�\|�Archives�\|�People�\|�Topics	Wine Latest�\|�Archives�\|�People�\|�Topics	GNUe Latest�\|�Archives�\|�People�\|�Topics
Czech

1.	16�Apr�2002�-�19�Apr�2002	(5 posts)	Building Incremental Patches
2.	16�Apr�2002�-�19�Apr�2002	(29 posts)	Support For USB Local Host (Target) Devices
3.	19�Apr�2002�-�23�Apr�2002	(10 posts)	Some Discussion Of 2.4 Support For Promise Cards
4.	22�Apr�2002�-�23�Apr�2002	(5 posts)	CPU Affinity With O(1) Scheduler Under 2.4
5.	22�Apr�2002�-�23�Apr�2002	(3 posts)	FrameBuffer Code Using BitKeeper

Kernel Traffic #164 For 28�Apr�2002

By Zack Brown