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

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

On Mon, 2005-10-24 at 16:41 -0400, Luben Tuikov wrote:
> > 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.
> 
> Again, no file name or line number, plus at that point I can see that
> this is going nowhere, well past the "all of this functinality...".

I consider scsi_transport_spi.c to be a file name.  Try lines 38-1219.

> > I think you don't quite understand what a generic device is:  It's a
> 
> Hey, in those recent threads, I've been told by you and Jeff that I don't
> understand anything.  Why does this now surprise you?  Apparently only you
> and Jeff understand everything.  Can we move on now.
> 
> > 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.
> 
> Again, domain devices should stay only in the transport layer.  There
> is no _need_ to represent them with "generic device" as they have
> no _meaning_ outisde the transport (layer).

Um, that's not what you said here:

http://marc.theaimsgroup.com/?l=linux-scsi&m=112887522221936&w=2

You said:

> struct scsi_domain_device { ... }; (to be created) is your friend.
> 
> The only way that that design
> 	"should be capable of representing any 
> 	 SCSI domain (FC/SPI/SBP etc ..)"
> 
> Is if it _does not_ have any knowlege about the underlying
> physical domain -- just as it is shown in SAM (and that is the whole point).
> Else you get in this neverending cat-and-mouse game.  If you have the
> abstraction right, then whatever new transport comes along, it would
> be properly represented.

So that's precisely a generic domain device.

But my point is that what's in include/device.h which the kernel calls a
generic device is simply an abstraction that has certain useful
properties; properties which we make use of.  Identical to the way a
kobject has a more limited set of useful properties.

> >>>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.
> 
> The vanilla kernel has nothing, not even remotely similar to what
> I have in the SAS Stack.  Other than the USB and SBP code.

You've changed the grounds.  Your original claim was that the added
properties weren't opaque, which they are.

> >>>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
> 
> It *is not*.  What your "transport attribute classes" are is a work around
> SDI.  The template they stem off of, transport_class, is just exporting
> _attributes_.

No, that's what you keep trying to claim they are.  In fact they're
attributes coupled with library functions.  A good example being
spi_dv_device(struct scsi_device *sdev) which performs Domain Validation
(an SPI specific function) on a given SCSI device.  That is contained
within the SPI transport class and definitely isn't an attribute, it's a
service used by SPI specific drivers.

> For example take a look at the event management in the SAS Stack.  Take
> a look at all other things it implements.  Such concepts belong to
> a separate layer, which doesn't yield to generalization as you've tried
> to do.

In the transport classes, layer specific code is confined, that's what
the spi_ functions do in the spi transport class.  There's no equivalent
in the generic code, it's just a template builder for the transport
specific code.

> > 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.
> 
> FC is the last example I'd look at as far as anything "proper" is to
> be implemented.  I mean how many variations did it go over?

Ah, so you accept that the FC transport class does do this but you just
don't want it to be admitted as a valid example because the class grew
organically?  As Jeff has tried to explain, that's how linux development
goes.

James