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

[Luben Tuikov <luben_tuikov@adaptec.com>]

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.

Hi Andre,

Let me know if this satisfies:

The infrastructure is broken into
	* SAS LLDD,
	* SAS Layer.

The SAS LLDD does phy/OOB management, and generates SAS events
to the SAS Layer.  Those events are *the only way* a SAS LLDD
communicates with the SAS Layer.  If you can generate 2 types
of event, then you can use this infrastructure.  The first two
are, loosely, "link was severed", "bytes were dmaed".  The third
kind is "received a primitive", used for domain revalidation.

A SAS LLDD should implement the Execute Command SCSI RPC and
at least one SCSI TMF (Task Management Function), in order for
the SAS Layer to communicate with the SAS LLDD.

The SAS Layer is concerned with
      * SAS Phy/Port/HA event management (LLDD generates,
        SAS Layer processes),
      * SAS Port management (creation/destruction),
      * SAS Domain discovery and revalidation,
      * SAS Domain device management,
      * SCSI Host registration/deregistration,
      * Device registration with SCSI Core (SAS) or libata
        (SATA/PI), and
      * Expander management and exporting expander control
        to user space.

The SAS Layer uses the Execute Command SCSI RPC, and the TMFs
implemented by the SAS LLDD in order to manage the domain and
the domain devices.

For details please see drivers/scsi/sas/README.

The SAS Layer represents the SAS domain in sysfs.  For each
object represented, its parent is the physical entity it attaches
to in the physical world.  So in effect, kobject_get, gets
the whole chain up on which that object depends on.

In effect, the sysfs representation of the SAS domain(s)
is what you'd see in the physical world.

Hot plugging and hot unplugging of devices, domains and subdomains
is supported.  Repeated hot plugging and hot unplugging is
also supported, naturally.

SAS introduces a new physical entity, an expander.
Expanders are _not_ SAS devices, and thus are _not_ SCSI devices.
Expanders are part of the Service Delivery Subsystem, in this case
SAS.

Expanders are controlled using the Serial Management Protocol (SMP).
Complete control is given to user space of all expanders found
in the domain, using an "smp_portal".  More of this in the second
and third email in this series.

A user space program, "expander_conf.c" is also presented to show
how one controls expanders in the domain.  It is located here:
drivers/scsi/sas/expanders_conf.c

Thank you,
	Luben

> 
> 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.
> 
> 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).
> 
> Cheers,
> 
> Andre
> 
> PS I didn't listen to that advice back then, don't make the same mistake.
> 
> 
>