Kernel Traffic #243 For 1 Dec 2003

http://www.zip.com.au/~akpm/linux/patches/2.6.0-test9-mm3.gz

kernel.org is being slow. Will appear at:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/

• Various new fixes; generally uncritical ones.
• Significant changes to the AIO and direct-io code. This needs beating on; hopefully we're now close to a solution to the fairly complex problems in there.
• Several ext2 and ext3 allocator fixes. These need serious testing on big SMP.
• Anyone who has patches in here which they think should go into 2.6.0, please retest them in -mm3 and let me know, thanks.

Triple faults you can't debug, they raise a line outside the CPU, and normal PC hardware will cause that to just trigger a reboot.

But double faults do get caught, and that debugging stuff actually is in the standard kernel. It won't give _nearly_ as good a debug report as a "normal" oops, since I didn't want the double-fault handler to touch anything even remotely unsafe, but it often gives a good hint about what might be wrong. Certainly better than triple-faulting did (which we still do for _catastrophic_ corruption, eg totally munged kernel page tables etc - it's just very hard to avoid once you get corrupted enough).

Since some vendors refuses to release specs or even a binary Linux-driver for their WLAN cards I desided to try to solve it myself by making a kernel module that can load Ndis (windows network driver API) drivers. I'm not trying to implement all of the Ndis API but rather implement the functions needed to get these unsupported cards working.

Currently it works fine with my Broadcom 4301 but I would like to get in touch with people that have similar cards that are willing to do some testing/hacking.

Visit this page for more info: http://ndiswrapper.sourceforge.net/

Please! I don't want to start a flamewar if this is a good thing to do. I'm just trying to scratch my own itch and I doubt that this project changes the way Broadcom treats Linux users.

are you loading these drivers into ring 0 (kernel space)? As far as I know linux only supports ring 0 (kernel) and 3 (userspace). However this would seem to be the perfect place to load the binary modules in ring 1 (or even userspace if that was possible...). I can't say I trust any binary only and/or windows driver to not make a mess of my kernel :) actually the driver may actually be errorless - it's just designed for a different operating system and thus some unexplainable misshaps could easily happen...

While we're at it, loading binary only modules into ring 1 would probably also be a good idea for the NV module et al. Although I have no idea how hard it would be to make ring 1 function (and whether there actually is any point to doing it in ring 1 instead of ring 3 with iopl/ioperm anyway) and how big the performance penalty for non-ring 0 would be...

Do the NDIS drivers work in 32-bit land? Some kludges do! They were the real-mode DOS driver interface to MS-DOS. Now there is a kludge on top of a kludge called NDIS-6. They also used the Pascal calling convention which screws up 'C' code (you need an assembly wrapper).

They are a waste-of-time. Why would you clone a Microsoft interface for a non-Microsoft Operating System when you can't allow such junk to run inside the kernel anyway.

The problem with third-party binary drivers is not the interface to the kernel. Linux has a public interface, well established and well known. The problem is that any third-party driver can completely f**k up the kernel, either by mistake or by design. So the third-party drivers MUST provide source-code so they can be fixed or made to behave if (read when) problems are found.

That may be the politically sensitive (except to Intel) correct answer, but in the end I suspect that the _real_ answer is that ring 1/2 are just fundamentally useless, and it has nothing to do with x86 implementation semantics or anything else.

Any kind of reasonable performance driver requires direct access to the buffers it is going to fill in. And not just the actual data contents, but to the metadata too - the pointers that comprise the skb (or in BSD, mbuf) lists, etc.

So even if you were to use ring1/2 for the driver, you'd really need to give write access to a large portion of the data structures that the "core" kernel networking would use.

Which means that you either put the core kernel in ring1/2 as well (at which point you don't actually use ring0 for anything interesting at all - you could put a microkernel there, but hey, there's no real point), or you map in a _lot_ of ring0 metadata into ring1/2, at which point you lost the whole point of using a different protection domain.

And quite frankly, if you're willing to actually dynamically map all the ranges and be careful, why use ring1/2 at all? You might as well use ring3 and make the whole thing be a user-mode wrapper. You'd never perform really well, but for debugging it is acceptable.

Anyway, whatever way you turn, ring1/2 just don't actually _give_ you anything. Which is, in the end, the _real_ reason nobody uses them.

(I agree, the fact that the x86 paging hardware makes 1/2/3 be equivalent makes it an even _less_ useful abstraction, but I think it is a mistake to think that it would be any more useful even if the page tables wasted precious bits on unnecessary level information).

Multi-ring was a failure. Let it go. The only reason it is making something of a comeback (Palladium-whatever-it-is-called-today) has no good technical reasons, and is purely about other things.

The good people at Cambridge made a (very nice) VMM that exploits ring0/1/3 to let one machine run various kernels independently (the kernels need to be ported to the xen arch).

Xen itself executes in ring0 and the "guest" operating systems execute in ring1. User code runs in ring3, as usual. They have linux running under xen ;)

The project's home page is at http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ and one paper describing the whole thing is here: http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf

This is what I alluded to a few lines later - saying that if you move the driver down to ring1, then you should move _everything_ down to ring1 and just leave a microkernel at ring0.

Now, I'm not big on microkernels, but a pure virtual machine abstraction is at least not the distateful academic mental masturbation that we saw in the 80's.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm4/

• Several fixes against patches which are only in -mm at present.
• Minor fixes which we'll queue for post-2.6.0.
• The interactivity problems which the ACPI PM timer patch showed up should be fixed here - please sing out if not.

Here it goes -rc2.

Important netfilter fixes, several ACPI fixes, few driver corrections (tulip, tg3, megaraid2), amongst others.

If no problems shows up this should become final in a few days.

I've released the 006 version of udev. It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-006.tar.gz

Due to me being on paternity leave for all of November, I've not built up any rpms, but the spec file is in the tarball, so you can do it if you wish.

udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run.

The major changes since the 005 release are:

• rules now are applied in the proper priority, instead of the order they showed up in the config files.
• partitions work properly for all types of rules, instead of just the LABEL rule type.
• format modifiers have been added so that the NAME is now dynamic. See the udev.config file and the man page for more documentation about these (NOTE, if you have any rules that named partitions in the past, they will have to be changed to take advantage of these modifiers in order to work properly now.)
• subdirectories under /udev are now handled properly.
• better parsing logic can handle broken files saner.
• added
• moved the tests to a test/ directory, along with the beginnings of a regression test suite.
• lots of tiny fixes

Many, many thanks to Kay Sievers, for this release, for implementing many of the new features. I really appreciate it.

Thanks also to Dan Stekloff, Robert Love, Paul Mundt, Chris Friesen, Arnd Bergmann, and Olaf Hering, all of whom submitted patches for this release.

The full ChangeLog can be found below.

The udev FAQ can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

The udev BitKeeper tree has moved for now, due to kernel.bkbits.net being off the air to: bk://linuxusb.bkbits.net/udev

Note, to build using klibc, please read the klibc README in the klibc/ directory, and build using 'make -f Makefile.klibc'.

If anyone ever wants a snapshot of the current tree, due to not using BitKeeper, or other reasons, is always available at any time by asking.

Oops, two more major changes I forgot to mention:

• udev.permissions can now handle wild cards. So the following line would apply for all ttyUSB devices:
  ttyUSB*:::0666
• I've added two external programs to the udev tarball, under the extras/ directory. They are the scsi-id program from Pat Mansfield, and the multipath program from Christophe Varoqui. Both of them can work as CALLOUT programs. I don't think they currently build properly within the tree, by linking against klibc, but patches to their Makefiles to fix this would be gladly accepted :)

Thanks a lot to both Pat and Christophe for letting me include their programs in the main udev release, I appreciate it. And if there's any other small programs that people want me to bundle within udev, please let me know.

I am guessing its more driver support, etc. Input devices for instance do not seem to have any sysfs support yet, and full initramfs support with udev in there, and udev.permissions setup to get general permissions, etc right, might make it more advertisable for the masses (no need to maintain /dev or the initial costs for users not so interested in the workings of things).

Lets just say from what I have seen from users talking/asking, the initial setup and seeming 'lack of functionality' is the biggest blocker.

my cuecat driver is ready for testing.

http://zinx.xmms.org/cuecat/cuecat-2.6-0.0.2.tar.gz

It does not use the same output format as the driver floating around for 2.2.x/2.4.x kernels.

It currently requires a patch which changes the order serio drivers are searched in (the newest driver is searched first now), and adds a function to walk through the serio port list.

I'm hoping the patch will be included in to the kernel at some point in time -- It's available separately at: http://zinx.xmms.org/cuecat/linux-2.6.0-test9-serio.diff

The driver has some pitfalls, such as standing between -all- serio devices capable of supporting a cuecat, and not just the ones with a cuecat on them (And it has no way to specify which ports to use), but hopefully I'll think of a good way to fix that before 0.0.3.

The major number is dynamicly allocated -- If you aren't using devfs, check /proc/devices.

The minor number for reading all cuecats is 0, and the minor number for individual cuecats is their [driver-assigned] index plus 1. Recommended names are:

/dev/cuecat/cuecats
/dev/cuecat/0
/dev/cuecat/1

and so on.

The input core really is designed for actual input devices, rather than devices that send out arbitrary largish amounts of data.

The driver would probably be simplified a bit (superficially) by sending barcodes as events (it would have to be multiple events per barcode -- the input core has very small communications with userland), but it would complicate userspace quite a bit, and it's really just not the sort of thing I'd expect in the input core.

However, if you can think of a way to send the barcodes as a single event, without changing the userland input core interface, I'm all ears :)

For those who like data visual, i've created some graphs comparing various STP test runs. I'm using 2.6.0-test9 and 2.4.22/23-rc1 as comparison targets. Data updated as new tests run on STP.

Graphs here: http://developer.osdl.org/cliffw/reaim/compares/index.html

Other test runs here:

http://developer.osdl.org/cliffw/reaim/index.html

Reaim test code here: http://sourceforge.net/project/showfiles.php?group_id=71019

There is a difference between 2.4 (tested in 2.4.23-rc2) and 2.6 (tested in 2.6.0-pre9) in the handling of "int 3" inside a SIGTRAP handler.

In 2.4, the handler appears to be recursively re-entered. In 2.6 the task is killed, along with any other tasks that share the same VM (I'm not talking about thread groups; I have CLONE_PARENT and CLONE_VM set but not CLONE_THREAD).

I'm not sure what the correct answer is, if indeed it's specified. For contrast, in FreeBSD 5.1 I'm told that the signal handler runs to completion and only on exit is it called again. I would suggest that this behaviour is probably more in keeping with the principle of least astonishment, but maybe I astonish in atypical ways.

The basic change is basically:

• some signals are "thread synchronous", ie the thread _cannot_ continue without taking them. Basically, any instruction fault does this, since just returning would generally cause the instruction to just be done again, and cause the same fault.
• the difference between 2.4.x and 2.6.x is that in 2.4.x such a thread-synchronous instruction will just blow through being blocked. So even if you block them, they'll still happen. In 2.6.x, trying to block a thread-synchronous signal will just cause the process to be killed with that signal ("it can't be delivered, it can't be ignored, let's just tell the user")

The reason for the change is that the 2.4.x behaviour ends up hiding bugs, and can cause surprising deadlocks in threaded programs. The 2.6.x behaviour is "You did something fundamentally wrong, just _die_ now".

This works because "int 3" and "into" is what Intel calls a "trap" as opposed to a "fault", and as such we _could_ delay handling the signal and just continue along - when the exception happens, the CPU has already executed the instruction, and the exception will return to _after_ the instruction.

However, Linux will refuse to do that because delaying the SIGTRAP is pointless:

• you'd get it at the wrong spot, making it pointless
• the wrong thread could get it if you just consider it a normal signal.

So Linux considers both "int 3" and "into" to be thread-synchronous, even though they are trivially recoverable. Which means that we have two options, and two options only: punch through the fact that the signal is blocked, or just say "that's wrong", and kill it.

NOTE NOTE NOTE!! If you actually _want_ the 2.4.x behaviour of recursive signal invocation, you should just tell the kernel so: use the SA_NODEFER flag to sigaction() to tell the kernel that you don't want to defer recursive signals.

In short, the 2.6.x behaviour is the right one. 2.4.x was a strange violation of the signal blocking, and I consider the FreeBSD behaviour to be just bizarre.

And with 2.6.x, if you actually _want_ recursive signal handlers, you can do so (fairly portably, I might add - putting the SA_NODEFER flag there should make everybody do the same thing, even *BSD).

Occasionally I have had a situation where the init process hits an instruction fault (often because of a kernel bug, actually), such as an access to a bad address. On embedded platforms we sometimes get the situation where init uses floating-point instructions but the CPU doesn't have floating point and the kernel has been compiled without FP emulation. In these situations the system looks like it just hangs, since init is doing nothing but take the same signal over and over again.

In this case the signal would not actually be set to be blocked or ignored but would end up being ignored because of the rule that "init gets no signals it doesn't want". I would prefer to see thread-synchronous signals kill init if they are not handled, so that at least we get a panic with a message that says what went wrong rather than the system just spinning its wheels uselessly.

Hmm.. Right now the init special case is in the signal _delivery_ path, which makes it hard to do something like that, since by then we no longer know/care who sent the signal.

We could move the special case into the send path instead (and then only do it for "external signals" and not special case init at all for internal signals).

Hmm.. Looking at the signal sending code, we actually do special-case "init" there already - but only for the "kill -1" case. If the test for "pid > 1" was moved into "group_send_sig_info()" instead, that would pretty much do it, I think.

Feel free to try something like that out. I'm not going to apply it right now, though ;)

Why do we bother special-casing init at all?

It seems the only things init can't ask the kernel to do already for it is to block SIGSTOP and SIGKILL, and it seems that if you killed (or stopped?) init you should just get the kernel panic.

If there is anything that should be special-cased, then perhaps it should be that init should be allowed to block/catch/ignore SIGSTOP/SIGKILL. Perhaps that should be a capability?

Because the kernel depends on it existing. "init" literally _is_ special from a kernel standpoint, because its' the "reaper of zombies" (and, may I add, that would be a great name for a rock band).

So without init, the kernel wouldn't have anybody to fall back on when a parent process dies, and would become very very unhappy. Historically it actually oopsed the kernel.

UNIX semantics literally _require_ that "getppid()" should return 1 if your parent dies, and that's "current->p_parent->tgid". So we have to have a parent with pid 1, and thus init really _is_ special.

Yeah, we could have _other_ special cases (we could create another process that is invisible and has pid 1), but the fact is, _some_ special case is required. It might as well be "you can't kill init".

We still don't have an HT aware scheduler, which is unfortunate because weird stuff like that looks like it will only become more common in future.

I made a patch on top of my recent NUMA/SMP scheduling stuff to implement generalised scheduling classes. With this modification we can allow architectures to control scheduling policy in a much finer way. Hyperthreading should be no problem, hierarchical (NUMA) nodes should be doable as well.

I'm not exactly sure how architecuture specific code is supposed to be handled, I'll have to have a look at some examples. Basically architectures build up your own scheduling "classes".

I have supplied a default function to build up the classes if none is supplied. It builds them so functionality should be similar to the previous standard local / remote behaviour.

Haven't done much testing yet, just asking for comments. Will these classes be sufficient for everyone?

Class is struct sched_class in include/linux/sched.h Default classes are built by arch_init_sched_classes in kernel/sched.c

http://www.kerneltrap.org/~npiggin/w23/. The patch in question is this one: http://www.kerneltrap.org/~npiggin/w23/broken-out/sched-domain.patch

Version 2.6.2 of perfctr, the Linux/x86 performance monitoring counters driver, is now available at the usual place: http://www.csd.uu.se/~mikpe/linux/perfctr/

I've now also made .rpm files for the user-space components. Please try them out and report any glitches.

Version 2.6.2, 2003-11-23

• libperfctr.so is now installed with proper versioning.
• ABI control and info structures padded to accommodate some extensions without breaking application/library binary compatibility. ABI version incremented to '5'.
• Driver checks that only P4 models <= 2 use IQ_ESCR0/1.
• Added support for Fedora Core 1's 2.4.22-1.2115.nptl kernel.
• Driver compile fix for AMD64 in SMP 2.6 kernels.

I've released the 007 version of udev. It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-007.tar.gz

udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run. Please see the udev FAQ for any questions about it: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

Note:

The CALLOUT rule format has changed. If you have a config file using this rule, please change it to follow the new order. See the man page for the proper style.

The major changes since the 006 release are:

• better parsing of the udev.permissions file
• string owner and group names in the udev.permissions file will now work if you build against glibc.
• fix the CALLOUT rule to look the same as the other rules.
• add format char for CALLOUT rule output
• support arguments in callout exec
• add ability for CALLOUT program to accept format modifiers.
• drop Makefile.klibc. To build using klibc, use:
  make KLIBC=true
• updated man page documenting new changes.

Again, many thanks to Kay Sievers, for lots of great patches in this release. Thanks also to Marco d'Itri and Olaf Hering, both of whom submitted patches for this release.

I think with the ability to capture the output of the CALLOUT rule, combined with the ability to put format modifiers in the CALLOUT program string, we now have everything in place to emulate the existing devfs naming scheme. Anyone want to verify this or not?

The full ChangeLog can be found below.

udev development is done in a BitKeeper repository loacated at: bk://linuxusb.bkbits.net/udev

Daily snapshots of this tree can be found at: http://www.codemonkey.org.uk/projects/bitkeeper/udev/. Many thanks to Dave Jones for managing this.

it's been almost a month between test9 and test10, with a constant but diminishing trickle of small patches. The full changes are slightly larger than I was hoping for, but considering that the patch is barely over 100kB compressed for a month worth of work, I'm still fairly pleased.

There is still something strange going on that seems to be triggered by preemption, so for now we suggest not enabling CONFIG_PREEMPT if you want the highest stability. On the other hand, I'd love to have more testing, so that we can try to figure out what the pattern is - but please mention explicitly that you ran with preemption if you have problems.

Quite a lot of the -test10 patches are one-liners and quite trivial. I've tried to be quite strict in patch acceptance, so the changes are largely fixes for things that can crash the machine, and they are also of the type "this can't possibly break anything". But hey, we all know that theory and practice don't always match ;)

I'm planning/hoping on basically turning this over to Andrew, and let him decide to make the final 2.6.0 or not. Timing-wise Andrew is apparently going to be off for a few weeks, so regardless of whether this turns out to be rock solid or not, we'll have a few weeks of final testing before that were to happen. Which means that I might still end up making a test11 if Andrew hasn't come back and we find something that warrants it.

Btw, I'm happy to say that maintainers have been self-policing themselves quite admirably. Thanks to everybody involved.

The changelog gives more details, but the bigger things here are various networking fixes, and the SCSI layer being better at refcounting some data structures (the oopses on USB storage removal that some people have seen should hopefully be fixed).

[ Btw, I tried to come up with a good name for this release. But the fact is, that as Scott Adams has so often pointed out, you can't do much better than "weasel" when it comes to funny. Ever since the "greased weasel" series of kernel releases I have been stuck for a good name.

This release is tentatively called the "stoned beaver" release (beavers are _almost_ as good as weasels, as I'm sure Scott Adams would agree).

If you feel strongly about the issue, please send your votes and ideas to "feedback@beaver-overlord.com", I'm sure somebody will find your insight fascinating.

Thank you in advance. ]

Linux 2.6 Compile Statistics (gcc 3.2.2) Warnings/Errors Summary

Kernel         bzImage    bzImage  bzImage  modules  bzImage   modules
             (defconfig)  (allno)  (allyes) (allyes) (allmod) (allmod)
-----------  -----------  -------- -------- -------- -------- ---------
2.6.0-test10   0w/0e       0w/0e   170w/ 0e  12w/0e   3w/0e    209w/0e
2.6.0-test9    0w/0e       0w/0e   174w/ 0e  12w/0e   3w/0e    217w/0e
2.6.0-test8    0w/0e       0w/0e   178w/ 0e  12w/0e   3w/0e    219w/0e
2.6.0-test7    0w/0e       0w/0e   173w/ 1e   8w/0e   3w/0e    226w/0e
2.6.0-test6    0w/0e       1w/0e   188w/ 1e  12w/0e   3w/0e    260w/2e
2.6.0-test5    0w/0e       2w/0e   205w/ 9e  15w/1e   0w/0e    305w/5e
2.6.0-test4    0w/0e       2w/0e   797w/55e  68w/1e   3w/0e   1016w/34e
2.6.0-test3    0w/0e       2w/0e   755w/66e  62w/1e   7w/9e    984w/42e
2.6.0-test2    0w/0e       1w/0e   952w/65e  63w/2e   7w/9e   1201w/43e
2.6.0-test1    0w/0e       1w/0e  1016w/60e  75w/1e   8w/9e   1319w/38e

Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Daily compiles (ia64):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running64.txt
Latest changes in Linus' bitkeeper tree:
http://linux.bkbits.net:8080/linux-2.5

Is anybody liasing, asisting or pressuring Intel wrt centrino wireless drivers?

It seems to me that it could have been written at least 20 times over during the time they've supposedly been in development.

This quote from back in March annoys me somewhat:

"The Santa Clara, Calif., chip maker is running Linux drivers in its labs, but whether or not those drivers make it out of the labs depends on customer demand, said Scott McLaughlin, an Intel spokesman"

Well, I am demanding, and my patience is running very thin. And Amd look to be releasing 64bit mobile parts soon, and appear to be very linux friendly. Am I the only one getting annoyed about this?

Can anybody put my mind at rest, or suggest reasons why Intel may be reluctant to release the drivers?

No, you're not alone... Although I don't have a Centrino-powered machine at the moment, the way Intel is behaving is stopping for me for even thinking on buying a new laptop replacement.

I think this kind of disinterest on Linux Centrino drivers is motivated by the fact that Microsoft has a strong relationship with Intel and since, like it or not, Windows has 90% of the desktop market, Intel doesn't see the motivation to spend a few hundred dollars in building the driver themselves.

However, they could at least release the documentation. Since the driver is, I think, going to be GPL'ed, they don't have to fear releasing the internals of Centrino.

We are pleased to announce Tinderbox-based tool which Linux kernel developers can leverage to flag defects and regressions in the Linux kernel and to relate these defects and regressions to recent change sets for the kernel. The tool is under continuing development and it allows for distributed testing of the kernel using multiple hardware platforms and software configurations.

This tool is derived from the Mozilla Tinderbox infrastructure, with much help from the kind people at Async (http://www.async.com.br/) The Linux Kernel Tinderbox is a client-server system: The clients do a continuous cycle of checking out, compiling and testing the latest code integrated into the source repository. The server provides output as a set of web pages, showing current changes to the kernel tree and state of the client machines. Client status is displayed as a set of time-ordered coloured boxes arranged into columns, one per client.

A prototype for the Linux Kernel Tinderbox is viewable at:

http://tinderbox.osdl.org/showbuilds.pl?tree=linux2.5-bk

Project documentation is located at:

http://www.osdl.org/cgi-bin/osdl_development_wiki.pl?Linux_Kernel_Tinderbox

This project will support any architecture capable of running Linux. It is our intent to encourage owners of these various hardware platforms to contribute Tinderbox clients.

The basic kernel tinderbox client is at: http://developer.osdl.org/cliffw/kernel_tinderclient.tar.gz

Support is via a mailing list: Kernel-tinderbox@lists.osdl.org http://lists.osdl.org/mailman/listinfo/kernel-tinderbox

Let us know if you can provide a non-Intel client machine

Attached to this email is a patch for a new ataraid sub-driver "iswraid" (Intel Software RAID) for Kernel 2.4 series. The patch is taken against Kernel 2.4.22.

The driver (along with the ata_piix driver) can be used with Intel's ICH5R chipset. You will need the Option ROM to do RAID configuration. This driver differs slightly from the other ataraid sub-drivers in that it operates on SCSI block devices rather than the ATA/IDE ones. "iswraid" depends on "ata_piix" driver to detect and load the SATA disks connected to ICH5R. Note that the driver is still considered experimental, use at your own risk.

Thanks to Arjan van de Ven (ataraid), Jeff Garzik (ata_piix) and James Bottomley (scsi) for patiently answering my questions.

FYI: ata_piix patch for 2.4.22: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/