RE: [SAS ANNOUNCEMENT] MPT Fusion driver 3.02.07.02 update

[James Bottomley <James.Bottomley@SteelEye.com>]

On Mon, 2004-11-15 at 18:11, Moore, Eric Dean wrote:
> On Monday, November 15, 2004 3:51 PM, James Bottomley wrote:
> 
> > This isn't an exercise to expose all the layers in the 
> > transport, merely
> > to separate them out logically when it's useful to do so.  Thus, it
> > would make sense to expose the link layer separately only if something
> > other than a PHY were going to be using it.  If that's not the case,
> > then link transport parameters can be safely stashed in the PHY layer.
> 
> I open to debate on this.  The link info is going to be providing properties
> between two phys.

Right, but phys are essentially point to point, so the link info is also
a property of the local HBA phy.

> Would the "scan interface" be able to call the LLD drivers
> with a SAS Address?  Here is our SMP passthru struct:
> 
> typedef struct _MSG_SMP_PASSTHROUGH_REQUEST
> {
[...]
> } MSG_SMP_PASSTHROUGH_REQUEST, MPI_POINTER PTR_MSG_SMP_PASSTHROUGH_REQUEST,
>   SmpPassthroughRequest_t, MPI_POINTER pSmpPassthroughRequest_t;

Actually, no.  What you're wanting is a network type of connection (open
HBA and send an addressed packet).  What I'm proposing is more like a
connected socket model: We expose in the transport class a file that
understands the addressing (like the scan file in the scsi_host class). 
You send a command to this asking for the transport specific address to
be attached and it appears as a device node.  You communicate with the
device node using SG_IO and remove it again when you've finished.  So,
the packets you send to the device node are pure commands and have no
need of any addressing or topology information (and hence can be well
understood by SCSI or SATA.

James