Subject: Re: CVS commit: src/sys/arch/i386/conf
To: Manuel Bouyer <>
From: Jason Thorpe <>
List: source-changes
Date: 05/23/2004 11:41:51
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On May 22, 2004, at 10:20 AM, Manuel Bouyer wrote:

> But umass isn't an ATA controller.

And neither is a USB flash disk a SCSI controller, but we still attach 
a "scsibus" to it, followed by an "sd".  Why, because it speaks the 
SCSI command protocol.  And the device behind umass_isdata speaks the 
ATA command protocol.  Otherwise, why would be be using "wd" there at 

> atabus provide methods for sending commands and transfering data to an
> ATA device. umass provide others.

You see, that's bogus.  "wdc" is what should providing those methods 
(and, really, that's *almost* what there is today).

> I don't see what another layer in the device tree would buy us, as
> there can be only one device (wd) attaching at thoses.

Not necessarily.

We (Wasabi) have been working on drivers for SATA controllers that can 
support disks and ATAPI devices, but which do not export the legacy 
task file register interface to the drives.  Instead, they provide a 
command descriptor interface, similar to the way a SCSI controller 
would, but they still use all of the same ATA commands that would be 
used with a "wdc" controller.

At the same time, there are things that the atabus layer provides which 
are useful, e.g.:

	* Drive discovery infrastructure
	* Some common functionality (ata_get_params(), ata_set_mode(), etc.)
	* Command queueing (this needs more work to actually queue stuff in
	  a real sense, but this is really where it should be).

In short, there is no reason that atabus should not be for ATA the same 
that scsibus is for SCSI.

         -- Jason R. Thorpe <>

content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

Version: GnuPG v1.2.3 (Darwin)