James Bottomley wrote:
> On Tue, 2007-06-26 at 12:44 +0200, Stefan Richter wrote:
>> If there are going to be sysfs representations of targets,
[...]
> OK, you've lost me ... this is our current sysfs representation of a
> disk:
>
> /sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0
>
> target0:0:0 is what I think of as the target ...
Strange. How did I miss this? #-|
Actually I missed this because I only looked into linux/include/scsi/*.h
and found
struct scsi_device {
...
struct scsi_target *sdev_target; /* used only for single_lun */
...
}
Is the comment wrong or is sdev_target something different?
> is that different from what you're asking for?
That's part of what I asked for. I also thought of SCSI core populating
it with certain attributes; let's call them port_name and port_id. 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.
If that's not wanted, then what is the way? Simply the following code
in a transport driver/class/whatever?
target_gendev = get_device(sdev->sdev_gendev.parent);
/* error check omitted */
err = device_create_file(target_gendev, &my_port_name_attr);
/* error check omitted */
err = device_create_file(target_gendev, &my_port_id_attr);
/* error check omitted */
put_device(target_gendev);
And I do this once, typically for the first sdev of each target?
(Repeating it won't hurt, just gives -EEXIST.)
--
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
