Upcoming plans for CAM

[Scott Long]

Matthew Jacob wrote:
> A couple of comments here from me......
> 
> a) Other than architectural cleanliness, what advantages to FreeBSD
> will accrue to replacing the ata driver with CAM access?

SAS controllers that expose SATA devices through STP need the upper
SCSI layers to understand ATA.  MPT is a bit unique in that it hides the
STP, SATA, and ATA details and pretends that all the world is SCSI/SAS
(for normal operation, I know that there's a special passthrough mode),
but many other controllers do not.

Secondly, I have plans for more transport independence than just 
ATA/SATA.  iSCSI, SAS, and FC can all benefit from not being treated
like SPI.  ATA/SATA just provides a quick and high-bang-for-buck 
demonstration of the merit splitting up the transport and protocol
support in CAM.

There are other reasons as well that are better discussed in private.

> 
> b) The NEW_TRAN code stuff is a way (not necessarily the cleanest) to
> try and be able to carry transport related metadata related to a
> periph. By and large the periph driver doesn't need to know transport
> related details. The exceptions to this are quirks which can only be
> safely derived from transport types and transport related values and
> identifiers that system management (or GEOM0 wants to know about (and
> really can only ask the periph driver about).

My intention is to continue to use and extend the NEW_TRAN code. 
Transport details that need to be worked out involve things like the
GET_TRANS and SET_TRANS operations.  I'm still thinking through that
in terms of cleanliness in the periphs.

> 
> c) All of #b is orthogonal to whether you have one periph driver or
> multiple periph drivers for the same fundamental 'type'. Perhaps the
> Win2K approach of allowing for selective binding (filter drivers)
> might be appropriate and would extend the current 'main' periph driver
> (e.g., "sa") plus the pass driver.

Right now, just about any periph can attach to a device.  The pass 
driver isn't really a special case, it just allows itself to attach to
all devices, whereas the other periphs look at the INQ info and are
selective.  I plan to allow this to continue.  I don't know a whole lot
about how filter drivers work in Windows, though.  Do the filters stack
on top of each other, or are they all peers on top of the same device?
It might be interesting to better encapsulate the periph API and allow
periphs to be loaded as modules (something that is close to working
already).  If filters are peers in Windows, so Windows provide any
arbitration or protection between peers?

> 
> d) Don't expect that ATA specific commands will just automatically
> tunnel, no matter what CAM changes are made. Different direct SATA
> controllers may have different requirements for being able to do
> arbitrary non-read/write commands. Tunneling HBAs (like mpt(4)) don't
> support the ATA passthrough CDB at all and instead require a special
> request structure.

If you're talking about STP, then that's basically the kind of thing 
that SIMs will have to support on their own.  The periph will send an
XPT_SCSI_IO or XPT_SATA_IO (or whatever other protocols come along) CCB 
to the SIM, and it'll be up to the SIM to either accept the CCB or not.
The encapsulation details will be left to the SIM.  Helper functions
might be developed for common schemes like STP, just like there are 
helper functions for SBP now.

Specifically for SATA controllers, all I'm expecting the driver to 
support is the IDENTIFY command and the various basic read/write 
commands.  I don't know of any standard way for an ATA controller
to support ATAPI without supporting the PACKET command, but that might
be a detail left to the SIM anyways, I don't know yet.

These are just my random thoughts as well, so don't take any oversights
or misunderstandings from me as deliberate =-)

Scott