Luben Tuikov wrote: > --- Stefan Richter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
