Re: WIP: ATA to CAM integration

: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

    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,
    including ours.

    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.

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>