Re: [PATCH RFC 1/3] add fc transport events

[Douglas Gilbert <dougg@torque.net>]

James Bottomley wrote:
> On Sun, 2004-06-13 at 16:44, Mike Christie wrote:
> 
>>I am not adding a host and a device transport class. I am structuring 
>>things so there is a single fc transport class.
> 
> 
> I don't think that's such a good idea.  A class is supposed to represent
> an interface on a device.  The host and scsi device should have separate
> interfaces.  The only reason we don't have any host interfaces in the
> transport classes is because no-one has yet had a reason to add one. 
> However, since the loop status is definitely a host property, you
> do...part of what's missing is an attribute showing the loop state.  SPI
> has a similar need; the host property there is LVD or SE, and we might
> be interested in transitions between them.

There are 4 categories of "devices" that we might try
to address:
   a) host (PCI side and SCSI transport side)
   b) transport service delivery subsystem
   c) target device server
   d) logical unit

Only a, b + c are associated with the transport in question.
In category b could be FC switches and SAS expanders. In
category d could be sATA, SPI or SAS disks behind a FC
target. So the logical unit doesn't necessarily belong to
the same transport as the initiator (especially in iSCSI)
as noted above by James.

So the end point of the transport is category c and according
to SPC-3 a target device server is addressed via "well known"
logical units (see section 8). [The standard requirement for a
device server to respond to lun==0 for INQUIRY and REPORT LUNS
is a related hack that allows a SCSI disk to double as a
target device server and a lu.]

Is our transport class design flexible enough for this level
of complexity?

Doug Gilbert