Re: [PATCH] zfcp: Report FCP LUN to SCSI midlayer

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Luben Tuikov wrote:
> --- Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> Do all these transports use the same *name* for the attribute holding
>> the target port identifier's?
> 
> Sure, it is "tpid".

In mainline's transport classes?  Or/and in your stack?  OK, I'm lazy, I
should look into the source.

>> In other words, is userspace able to find
>> the target port identifier without knowing which transport is at work?
> 
> How can that be?  The target port identifier is by definition
> a transport property?

Target Port Identifier is a property of targets.

Only /how its value looks like/ depends on transport protocols.  Doesn't it?

So let's put the can always in the same shelf, regardless of the flavor
of the soup in the can.

(That's really why I joined the discussion.  We already have all
userspace requirements covered in sbp2, regarding which properties to
expose how.  Except that we do it in sbp2's own place rather than a
place common to all transport layer implementations.)

> "Userspace" which you have in mind will be more interested in the
> device name and other ID properties as returned by the INQUIRY
> facilities.  Some are transport specific some are not.
> 
> Either way userspace can follow a pointer from the sysfs device
> entry to the transport, just as sg-utils and lsscsi does now for
> the SAS Stack (my version of it at least).

As a side note:  What I said was because I'm a lot SBP-2/3 biased and
didn't deal with other transports myself yet.  In SBP-2/3 we are only
interested in LUs, we are interested in the concatenation of TPI and LUN
for worldwide unique persistent identification of LUs, we get both from
IEEE 1212 facilities, and SPC support is not so extensive.

>> Regarding the TPID:  The /how/ should be left to the transport layer
>> implementation; but the /where/ should be uniform in all transports.
> 
> This maybe hard to do since the structure of the domain is different
> for different protocols.
> 
> Of course this can be hacked by using symlinks...

If there are going to be sysfs representations of targets, i.e. target
devices, can't we express the target--LU relationships as parent device
relationships?  Could also be grand-(grand-)parent device relationships.

If neither is possible with some transports, then we indeed have to
resort to explicit attributes, e.g. symlinks.
-- 
Stefan Richter
-=====-=-=== -==- ==-=-
http://arcgraph.de/sr/