Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/arch/i386/conf




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 all?

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 <thorpej%wasabisystems.com@localhost>

Attachment: PGP.sig
Description: This is a digitally signed message part



Home | Main Index | Thread Index | Old Index