<That's as may be, but IDE _is_ missing a lot of the nice features of
<SCSI that provide I/O concurrency.  No disconnection, no command queueing
<(tagged or simple), etc.  And of course there's no good error reporting,
<and no reliable way to flush the drive's cache when you're ready to turn
<the power off!

Not all are needed and not all of the controlers for DEC systems can either.

<No disconnection and no queueing mean that you spend a lot more time
<waiting for data to come back from the disks than you do with SCSI --
<the "no disconnection" bit means that if you try to sidestep that with
<multiple disks, you have to put each disk on its own *bus*...

Your talking protocal for the bus VS physical characteristics of the end 
device.  If I ask for a block from either they will provide it in roughly
(assuming the caches, seek time and spindle speeds are similar) the
same amout of time.

<Also, better SCSI host adapters have very smart engines on them that can
<let you queue up many transfers _on the host adapter_ and go back to what
<you were doing.  IDE requires much more host CPU involvement than that,
<even if you're doing DMA for the actual data.

It's possible to have all that smarts and more on the host adaptor for
IDE.  What's different is there is less bus overhead (and fewer features).

It's possible (people do it on PCs) to run multiple IDEs with serperate 
interfaces or IDE controllers that add intelligence and additional caching
while keeping the drives seperately bussed.  

The IDE interface is far cheaper than SCSI to implement and in the case 
of NetBSD right now it would be better documented and maybe run with out 
PIO!  The latter is an issue even if the IDE need more cpu intervention
it's got to be better than PIO through SCSI using 5380 chip!!!

Allison