Re: [patch 0/6] marginalize HCIL a bit

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

On Mon, 2005-10-24 at 13:18 -0400, Luben Tuikov wrote:
> >>All of this functionality and infrastructure is present in the
> >>SAS Stack and could be taken almost as is.
> > 
> > 
> > Amazingly enough, it's also already present in the transport classes
> > (see vanilla linux kernel source code).
> 
> 1. What are we talking about here?
> 2. File location, name and line please.  Thank you.

The best commented file is scsi_transport_spi.c; you can see how it adds
spi specific pieces to the scsi_target structure using the generic
transport class capabilities.

> > If you look at your domain device with all the sas pieces removed,
> > you'll see that scsi_target actually covers all the remaining bits
> > (there are one or two pieces covered by struct generic_device which you
> > have to have extra components for because you implemented kobjects
> > instead of a generic device).
> 
> And there is a reason for this: domain devices are NOT and WILL NEVER
> BE "generic device".  Domain device representations exist only in
> the Transport Layer.  What you seem to suggest with your "transport
> attributes" is this "appendages-modules" which intersperse everywhere
> in SCSI Core and LLDD like octopus's arms.  See USB Storage and SBP.

I think you don't quite understand what a generic device is:  It's a
structure which is embedded within other structures, exactly like a
kobject.  The reason for using generic devices instead of kobjects is
that they provide a wider range of useful functionality.

> > scsi_target contains a variable space for
> > the transport classes to use for their transport specific pieces (which
> > is where you could have put all the sas specific bits).
> 
> Absolutely NOT.  Those "transport specific pieces" should be completely
> OPAQUE to SCSI Core -- as you saw in my previous email, the
> "transport specific pieces" as you called them were 
> "void *domain_device;  /* opaque to SCSI Core */".

They *are* opaque to the scsi mid-layer.  Refer to the code in the
vanilla kernel.

> I guess the proper question to ask now is: "Can you envision it?"
> 
> > The only real difference is that under the current infrastructure scsi
> > targets aren't designed to stack.  Realistically, the way you have it
> > implemented, you have several different devices lumped into your domain
> > device (end, edge, fanout, sata) with different initialisations and
> 
> 1. How this is implemented is Layer dependent (USB/SBP/FC/SAS/iSCSI/etc).
> 2. A struct domain_device can be _only_ one of end/edge/fanout/sata/etc,
>    and only one of those.
> Only devices which _make_sense_ to SCSI Core are registered with SCSI Core,
> i.e. end devices.  Other type of devices (e.g. expanders) that are
> NOT SCSI devices are not registered with SCSI Core, neither should they
> be visible anywhere outside of the respective Layer (SAS in this case).

That *is* how the transport classes work.  The obvious example being a
FC rport which has no existence outside of the FC transport class and is
not understood at all by the mid-layer.  Refer to the code in the
vanilla kernel.

James