Upcoming plans for CAM

Matthew Jacob lydianconcepts at gmail.com
Sun May 6 17:04:02 UTC 2007


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?

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

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.

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.

just a few random comments....


More information about the freebsd-scsi mailing list