James Bottomley wrote:
> H:C is really mid-layer defined (although I'd like to get rid of C
> eventually). They really correspond to physical enumeration of the HBA
> devices. T (or I) is the one we think could be abstracted and placed
> within the gift of the transport, but so far there's been a lot of
> debate with few actual concrete proposals. L is basically defined by
> SAM for every transport, but I'm really unsure how it should be
> represented in all its SAM specified glory.
If we reduce this discussion to the sysfs representation, then there is
one important point to understand: The sysfs device path is
implementation-defined. It always has been, always will be. That's
inherent to sysfs.
So, having the current implementation-defined H:C:T:L in the sysfs
device path is alright.
Trying to squeeze the SAM LU identifiers and target port identifiers
into the sysfs path might not be such a good idea, exactly because there
is a number of different formats of these identifiers. We certainly
want to find devices in sysfs in a transport-independent way.
So these identifiers should go somewhere else. How about exporting
sysfs attributes for each sdev with common names like
logical_unit_identifier
target_port_identifier
initiator_port_identifier
but with transport-dependent contents? The various transport-layer
implementations can do this without hand-holding of the SCSI core; the
only thing that's important is that all transports use the same names
for these attributes. The attributes shall be human-readable and can be
used by system management software like udev, hal, lsscsi, whatever.
If SCSI mid-layer wants to control what attribute names are used but
wants to leave the formatting of the contents to the transports, add for
example something like:
struct scsi_transport_template {
...
int (* print_logical_unit_identifier)(char *buf,
struct scsi_device *sdev);
int (* print_target_port_identifier)(char *buf,
struct scsi_device *sdev);
int (* print_initiator_port_identifier)(char *buf,
struct scsi_device *sdev);
...
};
Then SCSI mid-layer creates and destroys the attributes and
transport-layer implementations deliver contents for them. The print_
hooks can also be used for debug printk's or the like if need be.
What's then left of the issues with H:C:T:L are the varying difficulties
that some transports have to fill in some more or less sensible values
in the mid-layer's variables corresponding to H:C:T:L. Well, actually
the values don't have to make a lot of sense because they are
implementation defined and not for users to draw conclusions from them.
Or is there more to it?
--
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
