WIP: ATA to CAM integration
dillon at apollo.backplane.com
Fri Jun 5 19:17:40 UTC 2009
: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.
Huh. Get up on the wrong side of the bed, Scott? Just remember who
started making the shit comments this time.
I have no interest with what FreeBSD is doing with CAM. My only interest
vis-a-vie this thread are the AHCI driver efforts by the various BSDs,
In particular, my interest is in NCQ, hot-plug support, and port
multiplier support, as these three items can put SATA/AHCI on-par
with dedicated SCSI controllers (at least once AHCI hardware revs
past the original spec). It is something very important
to all Open-Source OS projects as it consolidates the storage device
driver spec and removes a huge thorn in the sides of all the projects
with regards to the forward-support of new hardware.
IMHO the only SCSI command non-SCSI devices have to fake-up is IDENTIFY.
Everything else is a straight translation, and an easy one at that.
Even SENSE doesn't need to be faked-up all that much, one just sets
an AUTOSENSE flag bit and include the sense in the CCB. So interfacing
to CAM is not really a big deal. The SCSI command set is the only
cross-device portable command set that exists today, after all.
The only problem I have with the original CAM is that it didn't use a
dedicated thread for bus-reset/probe/scan/identify/attachment and
detachment. That's the only reason the original API was such a bitch
to deal with by device drivers. Fixing that fixes all the device
interaction issues for attachment/detachment. The API doesn't actually
change, but the recursive nature of the direct calls goes away and
greatly simplifies device drivers. That's the only thing I see wrong
with CAM, frankly.
So I applaud your efforts on cleaning up the attach/detach stuff in
FreeBSD, but it isn't my focus in this thread and not something I'm
interested in doing for the DragonFly project, beyond what I mentioned
above. Your comments are improper.
<dillon at backplane.com>
More information about the freebsd-arch