Hi,
A few days ago I talked about adding a atabus device, and a kernel thread 
per IDE channel. I now have some code ready that I'd like to commit.

The diff is at
ftp://antioche.lip6.fr/pub/bouyer/diff.atathread.gz
(not posted because it's big)

This adds a device (atabus) between IDE controllers and wd or atapibus, to
have each ATA channel show up in the device tree. Later there will be atabus
devices in /dev, so that we can do IOCTL on them.
Each atabus has its own kernel thread, to handle operations that needs polling,
e.g. reset and others.

Device probing on each bus it defered to the atabus thread creation.
This allows to do the reset and basic device probes in parallel, which reduce
boot time on systems with several pciide controllers.
Boot messages now looks like:

[...]
pciide0 at pci1 dev 3 function 0
pciide0: CMD Technology PCI0646 (rev. 0x03)
pciide0: bus-master DMA support present
pciide0: primary channel configured to native-PCI mode
pciide0: using ivec 1820 for native-PCI interrupt
atabus0 at pciide0 channel 0
pciide0: secondary channel configured to native-PCI mode
atabus1 at pciide0 channel 1
[...]
scsibus1: waiting 2 seconds for devices to settle...
wd0 at atabus0 drive 0: <ST320420A>
wd0: drive supports 16-sector PIO transfers, LBA addressing
wd0: 19458 MB, 39535 cyl, 16 head, 63 sec, 512 bytes/sect x 39851760 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66)
wd1 at atabus0 drive 1: <ST320414A>
wd1: drive supports 16-sector PIO transfers, LBA addressing
wd1: 19458 MB, 39535 cyl, 16 head, 63 sec, 512 bytes/sect x 39851760 sectors
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)
wd1(pciide0:0:1): using PIO mode 4, DMA mode 2 (using DMA data transfers)
atapibus0 at atabus1: 2 targets
cd0 at atapibus0 drive 0: <CRD-8483B, 2001/02/16, 1.01> cdrom removable
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 (using DMA data transfers)

The kernel thread also handle wdcwait() before sending a command, and resseting
the bus after an error, which should avoid the annoying system hang while the
kernel is busy-waiting at splbio for a device to complete its reset, or
when a device decide to fail in a hard way.

Using the kernel thread, I converted the ata and atapi control functions
(setting PIO and DMA modes, etc ...) from interrupt-driven to polled. It's
much simpler, and using interrupts here isn't critical since basically this is
only called after a channel reset.

The kernel thread and atabus device will be used for IDE hot-plug support,
and tagged queuing, on which I'll work next.

Most changes are in the MI IDE drivers, but front-end and machdep code doesn't
require much changes. All changes to bus front-end are to call wdcattach()
directly and not though config_interrupts() (kernel threads are created
after interrupts are enabled, so config_interrupts isn't needed any more).
machdep code which walks the device tree to find the root device needs to be
updated. I did macppc (because I could test), I'll do the others as problems
arrise (unless the portmaster does it before me :)

However, all kernel config files needs to be changed. I think I did most of
them (I know a few in i386/conf still needs to be adapted).
I compiled all the kernel for which I changed the config file; the one that
failed didn't fail because of the IDE code :)
I tested this on i386 (various pciide and a pre-ata ISA), macppc (wdc at obio)
and sparc64 (pciide)

I'd like to commit this saturday 3 or sunday 4 Oct, along with the pciide
split I'm going to talk about in my next mail.
Comments ?

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--