map gendisk (or blockdev) -> scsi_device
Hi all; what's the proper way to get the scsi_device structure from a gendisk structure? sd.c uses pointers through scsi_disk, but that structure is private to sd.c. Will I need to add an access function in sd.c or something?
-ed falk, [email protected]
Edward Falk wrote on Tuesday, July 12, 2005 5:38 PM
Quoted 4 lines
Hi all; what's the proper way to get the
scsi_devicestructure from a gendisk structure?sd.cuses pointers throughscsi_disk, but that structure is private tosd.c. Will I need to add an access function insd.cor something?
If you are sure gendisk points to a scsi disk, then I think you can get scsi_device through gendisk->queue->queuedata.
- Ken
Quoted 2 lines · Edward Falk
Hi all; what's the proper way to get the
scsi_devicestructure from a gendisk structure?
No.
Quoted 3 lines
sd.cuses pointers throughscsi_disk, but that
structure is private tosd.c. Will I need to add an access function insd.cor something?
You should revisit your code to not need access to the scsi_device structure, and follow the layering of the block and scsi subsystems.
Quoted 3 lines
You should revisit your code to not need access to the
scsi_devicestructure, and follow the layering of the block and scsi subsystems.
Maybe I should explain what I'm trying to do here.
Some of our software reads some of the values in /proc/ide/hda/. We're porting this facility to libata-based drivers in 2.6 and moving it to /sysfs/block/sda/. The sysfs show() functions will be given pointers to gendisk structures but will need to obtain information from the associated scsi_device structure.
Does anybody have any suggestions as to the "right" way to proceed?
meta:
I understand the layering of block vs scsi and so on, but I wonder why there's so much isolation in the kernel. Why should it be impossible to obtain the gendisk structure from the scsi_device structure, or to obtain the block_device structure from the gendisk?
-ed falk
Quoted 6 lines · Edward Falk
Quoted 3 lines
You should revisit your code to not need access to the
scsi_devicestructure, and follow the layering of the block and scsi subsystems.Maybe I should explain what I'm trying to do here.
Quoted 7 lines
Some of our software reads some of the values in
/proc/ide/hda/. We're porting this facility to libata-based drivers in 2.6 and moving it to /sysfs/block/sda/. The sysfsshow()functions will be given pointers to gendisk structures but will need to obtain information from the associatedscsi_devicestructure.Does anybody have any suggestions as to the "right" way to proceed?
Add or use the attributes under the scsi_device, then use the /sysfs/block/sd/device symlink to find the corresponding scsi_device.
This is similar to what udev and lsscsi use to find device attributes.
udev uses libsysfs (included with udev).
[elm3b79 patman]$ ls -l /sys/block/sdo/device
lrwxrwxrwx 1 root root 0 Jul 13 16:44 /sys/block/sdo/device -> ../../devices/pci0000:01/0000:01:0c.0/host2/rport-2:0-8/target2:0:8/2:0:8:0
[elm3b79 patman]$ ls /sys/block/sdo/device/
block device_blocked iodone_cnt model rescan state vendor bus driver ioerr_cnt queue_depth rev timeout delete iocounterbits iorequest_cnt queue_type scsi_level type
-- Patrick Mansfield
Quoted 3 lines
Add or use the attributes under the
scsi_device, then use the /sysfs/block/sd/device symlink to find the correspondingscsi_device.
Perfect! Thanks.
Quoted 2 lines · Patrick Mansfield
Add or use the attributes under the
scsi_device, then use the /sysfs/block/sd/device symlink to find the correspondingscsi_device.
yupp, the /sys/block/* attributes are really only meant to be for thing related to the actual block device, not the underlying hardware.
Quoted 8 lines · Christoph Hellwig
Quoted 2 lines · Patrick Mansfield
Add or use the attributes under the
scsi_device, then use the /sysfs/block/sd/device symlink to find the correspondingscsi_device.yupp, the
/sys/block/*attributes are really only meant to be for thing related to the actual block device, not the underlying hardware.
What is the difference between "actual block device" and "underlying hardware"?
-ed