Subject: Re: CVS commit: src/sys/arch/i386/conf
To: Manuel Bouyer <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 05/23/2004 11:41:51
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.
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 <email@example.com>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----