WIP: ATA to CAM integration

[Scott Long]

Matthew Dillon wrote:
> :Hi.
> :
> :After replying to several similar questions about my ATA plans last
> :time, I have decided to announce things I am working on now together
> :with Scott Long.
> :
> :While learning FreeBSD ATA implementation, I have found, that it has
> :numerous deep problems, from quite fuzzy APIs to different issues in
> :device detection and error recovery. Also, as soon as this
> :infrastructure was written many years ago, it has completely no support
> :for any kind of command queuing, which is normal for the most of modern
> :drives and controllers. Fixing all of this require many significant changes.
> :
> :Also, you may know, that SAS controllers and expanders allow attaching
> :SATA devices and port multipliers to them, by transporting ATA commands
> :...
> :project of making CAM a system's universal infrastructure for both SCSI
> :and ATA. This project is not about some kind of SCSI-to-ATA translation,
> :used by some OS, like OpenBSD. It is about extending CAM, to equally
> :support both SCSI and ATA worlds natively and integrate them as tight as
> :possible.
> :
> :...
> :Our code now lives in PERFORCE in scottl-camlock project branch. It is
> :in early development, but we already have there working CAM driver for
> :AHCI controller with command queuing and basic NCQ support, simple SATA
> :bus management code and ATA disk driver. I am able now to boot my system
> :and work from SATA drive on AHCI controller, using ATA disk driver,
> :having command queuing and NCQ enabled, read and write disks with SATA
> :ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only
> :with CAM, without using any part of ATA infrastructure.
> :
> :-- 
> :Alexander Motin
> 
>     The biggest issue with AHCI (and ATA) interfacing is that AHCI devices
>     attach either as DISK or ATAPI.  A device which attaches as a DISK
>     does not typically support ATAPI commands (though it would be an
>     interesting experiment to see if some did).  This means that no matter
>     what you do a SCSI<->ATA translation layer needs to do some significant
>     fake-ups for DISK attachments, similar to what OpenBSD does in their
>     SCSI<->ATA layer.  ATA DISK attachments simply do not support enough
>     of the SCSI command set for direct integration into CAM (IMHO).

CAM is being expanded to be a framework for scheduling, recovery, and
topology management, agnostic to the transport and protocol being used.
SPI and SCSI are being separated into transport and protocol modules,
and Alexander has been amazing and kind enough to start a SATA transport
and ATA protocol module.  Unlike Linux, OpenBSD, or anything else out
there, this is not a tacked-on library for speaking SCSI/SPI at the top
level and then translating it to something else at a lower level.  This
is about speaking native SBP/RBP/ATA at the periph level and native
SPI/PATA/SATA/FCAL/SMP/USB at the transport level.

So, before you continue to cast ignorant doubts on our approach and hawk
your incomplete wares, please at least look at what is being done on our
end, and make an attempt to ask some reasonable questions.

Scott