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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Luben Tuikov wrote:
> --- Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> 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/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux