[ moved to tech-kern ]

On Sun, May 23, 2004 at 11:41:51AM -0700, Jason Thorpe wrote:
> 
> 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.

It can also attach a atapibus followed by an sd.

>  And the device behind umass_isdata speaks the 
> ATA command protocol.  Otherwise, why would be be using "wd" there at 
> all?

Not really the ATA command protocol. We probably can't attach an atapibus to
it, for example. It also seems it can only do PIO.

> 
> >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).

And it's really what it is, in fact (I wasn't clear, here). The methods are
provided by wdc.c (and ata_wdc.c, atapi_wdc.c), ata only provide a set of
highter-level functions.
It's just that this wdc doesn't appear in the device tree between the
controller and atabus.

> 
> >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.

Yes, and when I worked on the ata code, I though such smart controllers would
appear, and made the code modular enouth to allow these kind of controllers
to be supported easily. At first they would need to attach wd and atapibus
on their own, but see below.

> 
> 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.

It is the same. It's umass which is special.
For your controllers, you should be able to attach a atapbus to it with a
minimum of work (if I remember properly, there are still a few calls to wdc
from ata. I didn't fix those before knowing what a "smart" controller would
be). If there are several controllers with the same characteristics, you
may want to have an equivalent of wdc_core (wich is composed of wdc.c,
ata_wdc.c, and atapi_wdc.c). We have:
fooide -> (wdc_core) -> atabus -> wd
                               -> atapibus -> ...
you could have
foosata -> (sata_core) -> atabus -> wd
                                 -> atapibus -> ...
wdc_core and sata_core don't need to appear in the device tree, it wouldn't
buy us anything.

Back to umass. We have:
umass -> scsibus -> ...
         atapibus -> ...
         wd

If we insert atabus then we can have
umass -> scsibus 
         atapibus(1) 
         atabus -> wd
                   atapibus(2) 
we can't remplace (1) with (2), because atapibus(1) uses the ATAPI command set
but not over ATA (maybe it's an ATAPI device on the other end, but the
USB device don't give us access to the ATA command protocol).
atapibus(2) probably won't work either, because I suspect these isdata devices
support a reduced set of the ATA commads (it probably doesn't support the
PACKET data protocol for example).

In the current config(8) system I can't see a way to say that an atapibus
can't be attached to an atabus if it's attached to a umass.
Also, it mean that the attach data of atabus would need to be made compatible
with scsipi_bustype. One more thing to keep in sync.

The current scheme allows you to attach different kind of controllers to
an atabus with minor work. But I think umass, because of its limitations
and because of the other kind of devices that can attach to it, should be
handled as a "controller + atabus" device, rather than "controller".
If we really want to have an atabus attached to umass_isdata, it would
probably make sense to have different devices for umass_scsipi and
umass_isdata, to clean up the device tree.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--