Hannes Reinecke wrote:
> why don't we stick with the original implementation like zfcp had it?
> We can simpley expand the midlayer to add an attribute 'lun'
> to each scsi_device. This would be the LUN as returned by eg
> REPORT LUNS.
> No translation, nothing. Would be easy to implement and would allow
> any administrator to map the h:c:i:l value to the 'real' lun.
I would also like to have the Target Port identifier in there. This, in
combination with the LUN alias Logical Unit identifier is useful for all
kinds of persistent device mapping.
The LUN could be the same data format (and display format) for all
transports == 8 bytes. SBP-3's native format is 2 bytes but we can
transform and print it in the 8 bytes format; shouldn't hurt.
Actually, the SCSI midlayer integer 'l' can be used as internal
intermediary data format as long as only those LUN variants are in
real-world use which can be losslessly transformed to and from SCSI
midlayer's integer 'l'.
The transport identifiers have transport-dependent data sizes, and the
display formats are not standardized. So that's requiring a little bit
more care than the LUNs but it isn't overly complicated either.
So,
- SCSI mid layer should maintain sysfs attributes for each sdev which
show Logical Unit identifier and Target Port identifier.
- Do we pass the LUN through to SCSI midlayer's sysfs code via the
theoretically lossy scsilun_to_int/ int_to_scsilun transformation?
- Do we pass the target port identifier through as a data member in
struct scsi_device, or as a hook "int (* print_target_port_id)(..);"
in struct scsi_transport_template?
- Do we also want initiator port identifier, initiator port name,
target port name, LU name? If so, create a subdirectory for that
whole bunch of additional attributes? (Most of these are just
optional. In case of SBP-2/3, the initiator port identifier is
totally uninteresting to userspace; the initiator port name is of
mild interest but can be retrieved elsewhere from sysfs by some
black magic.)
I am slowly working on loosely related stuff in the fw-sbp2
transport-layer driver and could produce a respective patch for the
midlayer infrastructure along the way, if nobody else does before me.
(Next weekend at the earliest.)
--
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
