Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

From: Luben Tuikov (luben_tuikov_at_adaptec.com)
Date: 09/30/05

  • Next message: James.Smart_at_Emulex.Com: "RE: I request inclusion of SAS Transport Layer and AIC-94xx intothe kernel" 
    Date:	Fri, 30 Sep 2005 14:34:42 -0400
To: Andre Hedrick <andre@linux-ide.org>

    On 09/30/05 03:36, Andre Hedrick wrote:
    > I stated I would help with SAS adoption because there is a SAS-Transport
    > model. I asked about a possible libadaptec + libsas, and still waiting to
    > see if you and adaptec are up for the task. Right now the only path open
    > is the one Jeff Garzik is putting forward along with James and Christop.
    > I have a vested interest in seeing SAS-Transport, otherwise I would have
    > cut and run a long time ago.
    >
    > These long email threads where everyone is shout from the top of their
    > hill never wins anything. After a while the hill becomes flat (from all
    > the stomping), and you become old and tired.
    >
    > LSI pointed out they mask there SAS in firmware and make it show up in a
    > scsi-like or scsi state. They also pointed out other vendors have taken
    > this road. Even if Adaptec did not go this way in hardware, there still
    > has to be a way to map into SCSI ... sheesh this is Adaptec known for
    > SCSI.

    Hi Andre,

    Let me know if this 4 section write up satisfies:

    Section 1: MPT, SCSI Core and JB's "transport attributes"
    ---------------------------------------------------------

    SPI drivers (say 5 years ago)
    -----------------------------
     hardware implementation (bus connect)
         firmware implementation (transport: SPI)
            LLDD (exports SCSI devices (LUs))
               SCSI Core
                  Command Sets

    MPT-based drivers (now)
    -----------------------
     hardware implementation (interconnect/physical)
    --> Transport Layer (firmware: FC/SPI/SAS/etc) <--
            LLDD (exports SCSI devices (LUs))
               SCSI Core
                  Command Sets

    As you can see SCSI Core is _unaware_ of the transport.
    The transport is completely implemented in FIRMWARE, relieving
    the LLDD from worrying about it. Theoretically/ideally the same
    LLDD would work for _all_ transports, since the FW would
    export LUs to the LLDD, which would in turn register
    those with SCSI Core.

    The layout is the same as before, achieving 100% backward
    software compatibility.

    MPT-based drivers + James Bottomley's "transport attributes"
    -------------------------------------------------------------
     hardware implementation
         Transport Layer <------+ FW/Transport dependent access method
            LLDD <---------- + LLDD dependent access method
               SCSI Core ---------------------'
                  Command Sets

    This picture is _identical_ to the one above, but
    I've also shown what the "transport attributes" achieve:
    They hook to the _LLDD_ to get to LLDD dependent way of
    accessing "transport attributes" (any transport). This is
    JB's template unifying _all_ transports.

    Note that this isn't a _management_ layer or infrastructure,
    since, it _does not lie between_ the LLDD and SCSI Core.
    It merely implements attribute exporting.

    Section 2: USB/SBP/SAS and SCSI Core
    ------------------------------------

      hardware implementation (interconnect/physical)
          firmware implementation (SDS: TMFs + Execute Command SCSI RPC)*
              LLDD (Coherent interface to SDS)
    --> Transport Layer (Transport common to LLDDs) <--
                     SCSI Core
                        Command Sets

    * SDS, Service Delivery Subsystem (see SAM 4.6)
      TMF, Task Management Function (see SAM 7)
      Execute Command SCSI RPC (see SAM 5.1)

    Most immediate difference from Section 1 is that
      - the Transport Layer is _above_ the LLDD (in top-down).
      - no need for LLDD/Firmware dependent access method
        to the Transport,
      - Transport is accessed in the same way across all
        LLDDs of the same transport (USB/SBP/SAS).

    Now since, the LLDDs all implement TMFs + Exec Cmnd SCSI RPC,
    you can have
      - a transport common error handling and
      - a transport common "attribute" access (sysfs),
    across all LLDD of the same transport directly from userspace.

    The reason the LLDDs all implement TMFs + Exec Cmnd SCSI RPC,
    is that the Firmware implements it, and the reason that
    the Firmware implements it is that the chip implements
    it (following the transport spec).

    That is, you can have _different_ LLDDs connecting you
    to the _same place_ (maybe not at the same time, depending
    on the transport).

    SCSI Core should be completely unaware of the
    Transport being used and Transport specific
    Error handling is common to all such Transport
    specific LLDDs (via TMFs): one for SBP, one for
    USB, one for SAS.

    The whole point of this USB/SBP/SAS Transport
    Layering is that you can access at each level,
    thus you can add new abstractions, e.g. SATL (libata),
    as is shown in the SATr06 spec.

    Furthermore, when you look at the USB/SBP/SAS chips
    you will see nothing about "scsi_host", and all about
    "transport".

    And the sysfs representation of the SAS domain is analogous
    to, say, the USB representation of the USB domain.

    Section 3: Legacy Thinking or Thinking Legacy
    ---------------------------------------------

    Traditionally Error Handling has been done in
    SCSI Core. The reason for this is that the first
    and only SCSI was Parallel SCSI and no other
    SCSI was around (and that SAM didn't exist back then).

    This is how we have the SPI-centric EH methods
    in the scsi host template right now:
            int (* eh_abort_handler)(struct scsi_cmnd *);
            int (* eh_device_reset_handler)(struct scsi_cmnd *);
            int (* eh_bus_reset_handler)(struct scsi_cmnd *);
            int (* eh_host_reset_handler)(struct scsi_cmnd *);

    This is fine for Parallel SCSI (SPI) but for other
    transports it doesn't quite satisfy.

    Let's admit it, with HCIL and with the EH, SCSI Core
    is still very SPI centric.

    But we should _not_ break legacy drivers and backward
    support, yet we have to face the future.

    The way we do this is we slowly, without disruption
    to older drivers introduce, in parallel, emerge
    a new, simpler, slimmer, faster SCSI Core, whereby
    we accommodate new infrastructures, yet, have 100%
    backward compatibility, via the current older
    SCSI Core. After all, both would be a bunch of
    functions in a bunch of files.

    If X works with Y, do not disrupt it. Fix it if
    it's broken. Introduce innovation, functionality,
    better design, but not at the expense of breaking
    legacy.

    To eliminate bugs, tweak old as little as possible,
    since you cannot test on _all_ hardware the old code
    works on.

    To achieve maximum innovation and relevance in the fast
    changing world of storage, create, innovate new
    better, more accommodating design and infrastructures.

    Section 4: Politics
    -------------------

    Let's face it: SAS is a new emerging technology.
    It will be the technology for the next 10-15 years,
    and *everybody* in Linux SCSI wants a piece of it.
    Everybody wants their name and contribution to it.

    This is fine, but we need people who clearly understand
    the technology and clearly understand what, how
    and why it works. We need well-read and well educated
    people. Linux dedication is fine, but protocol knowlege
    is needed too.

    Can Linux afford people who have never even read SAS
    to write SAS Code for Linux. Yes, sure. It is the
    Linux's ideology: "specs are cr@p".

    Conclusion
    ----------

    Even though the SAS Transport Layer follows an _already_
    establised layering infrastructure for more (less?) exotic
    transports such as USB and SBP, James Bottomley has resisted
    its inclusion in Linux SCSI.

    Have we lost our touch with the new calling it
    "non-traditional"? Will Linux become a dinosaur?

    I'm not sure how many times one can split the SAS code?
    Will there be enough for everyone?

    > Just an FYI, would suggest you cool your heels and listen for the quiet
    > responses. There is more heat than light right now; maybe this thread
    > will offset some of the cost in the energy criss. Will pass on advice
    > handed to me (when I was a maintainer) relax and listen, nobody is out to
    > get you (and they were right).

    Thank you Andre for the warm advice.

    James, Linus, can we have this driver in the kernel now, please?

    Thank you,
            Luben

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: James.Smart_at_Emulex.Com: "RE: I request inclusion of SAS Transport Layer and AIC-94xx intothe kernel"

    Relevant Pages