James Bottomley wrote:
> On Tue, 2007-06-26 at 17:47 +0200, Stefan Richter wrote:
>> To fill values into these attributes, transport layer
>> drivers/classes/whatever supply to SCSI core either strings or functions
>> which print strings into buffers. -> SCSI core controls that these
>> properties go into host*/target*:*:*/port_{name,id}. Transports control
>> how the values of these attributes look.
>
> Really, look at the fc code which already does it ...
Good, I did a kscope session now to get an idea of the "transport
classes" API and how the "XYZ Transport Attributes" drivers use it.
> to try to provide methods from the mid-layer would make this quite complex.
No, it's mostly trivial. Mid-layer can add its own attributes to
starget->dev as well as to sdev->sdev_gendev. As far as attribute
values are transport protocol dependent, the show functions of these
attributes can make use of sprintf-like functions to be supplied for
example by scsi_transport_template, as I mentioned earlier in the thread
in http://marc.info/?l=linux-scsi&m=118253907125635 . I can explain
this by a demo patch, if I find time at the weekend.
[...]
>> err = device_create_file(target_gendev, &my_port_id_attr);
[...]
> Not really ... look at scsi_transport_fc.c line 911 ... the entire
> transport class is designed to set attributes like this and manage the
> lifetimes of the underlying objects.
OK, thanks for the pointer into the source.
Of course the mid-layer doesn't have to provide attributes like I
suggested them --- because the alternative is that all or at least the
majority of transport drivers provide them on their own but use
*uniform* attribute names for them.
This is what we have at the moment:
- The scsi_tranport_fc.c transport driver supplies the Target Port
Identifier and Name in attributes of the starget->dev. The
attributes are called "port_id" and "port_name".
- The scsi_transport_sas.c transport driver supplies an
"rphy_sas_address" of which the Target Port Identifier could
presumably be obtained. I am not sure in which sysfs devices this
attribute is located and how these devices relate to starget->dev.
- The scsi_transport_iscsi.c transport driver supplies the
attributes "targetname" and "tpgt" of which the Target Port
Identifier could be obtained. I am not sure in which sysfs devices
these attributes are located and how these devices relate to
starget->dev.
- I don't know if scsi_transport_spi.c's attributes are suitable to
obtain object identifiers or object names.
- Luben's SAS stack obviously supplies the Target Port Identifier in
the grandparent of LUNS devices. The attribute is called sas_addr.
The Logical Unit Identifier is used as the sysfs name of LUNS
devices, i.e. as sysfs directory names.
- The sbp2.c transport driver supplies the concatenation of Target
Port Identifier and Logical Unit Identifier in an attribute of the
sdev->sdev_gendev. The attribute is called "ieee1394_id". sbp2.c
needs to be told though by a recently added module parameter to
use SAM-4 conforming formats for the identifiers. It's partly
SAM's fault because there is an editorial mistake in SAM regarding
what an SBP-3 target port identifier is.
- The fw-sbp2.c transport driver (candidate to eventually replace
sbp2.c) supplies the concatenation of Target Port Identifier and
Logical Unit Identifier in an attribute of the sdev->sdev_gendev.
The attribute is called "ieee1394_id" and conforms to SAM-4 formats
out of the box.
So, only the SBP-2 transport and the out-of-tree SAS transport expose
Logical Unit Identifiers and Target Port Identifiers. (sbp2.c has been
doing so for years.) Some of the other transports expose only Target
Port Identifiers. Object identifiers are exposed in non-uniform places
defined by the respective transport implementation.
--
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
