Export the RAW SCSI Inquiry to sysfs as binfile. This way the data can be
used by userlang without the need to have and ioctl or use the sg_inq tool.
Here is an example of the provided data
linux:~ # hexdump /sys/class/scsi_device/1\:0\:0\:0/device/inquiry
0000000 8005 3205 001f 0000 4551 554d 2020 2020
0000010 4551 554d 4420 4456 522d 4d4f 2020 2020
0000020 2e32 2e33
0000024
Signed-off-by: Johannes Thumshirn <[email protected]>
---
drivers/scsi/scsi_sysfs.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 9ad4116..5ecb65d 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -773,6 +773,29 @@ static struct bin_attribute dev_attr_vpd_##_page = { \
sdev_vpd_pg_attr(pg83);
sdev_vpd_pg_attr(pg80);
+static ssize_t show_inquiry(struct file *filep, struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t off, size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct scsi_device *sdev = to_scsi_device(dev);
+
+ if (!sdev->inquiry)
+ return -EINVAL;
+
+ return memory_read_from_buffer(buf, count, &off, sdev->inquiry,
+ sdev->inquiry_len);
+}
+
+static struct bin_attribute dev_attr_inquiry = {
+ .attr = {
+ .name = "inquiry",
+ .mode = S_IRUGO,
+ },
+ .size = 0,
+ .read = show_inquiry,
+};
+
static ssize_t
show_iostat_counterbits(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -957,6 +980,7 @@ static struct attribute *scsi_sdev_attrs[] = {
static struct bin_attribute *scsi_sdev_bin_attrs[] = {
&dev_attr_vpd_pg83,
&dev_attr_vpd_pg80,
+ &dev_attr_inquiry,
NULL
};
static struct attribute_group scsi_sdev_attr_group = {
--
2.5.0
On 08/13/2015 01:50 PM, Johannes Thumshirn wrote:
> Export the RAW SCSI Inquiry to sysfs as binfile. This way the data can be
> used by userlang without the need to have and ioctl or use the sg_inq tool.
>
userland!
> Here is an example of the provided data
>
> linux:~ # hexdump /sys/class/scsi_device/1\:0\:0\:0/device/inquiry
> 0000000 8005 3205 001f 0000 4551 554d 2020 2020
> 0000010 4551 554d 4420 4456 522d 4d4f 2020 2020
> 0000020 2e32 2e33
> 0000024
>
> Signed-off-by: Johannes Thumshirn <[email protected]>
> ---
> drivers/scsi/scsi_sysfs.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
Reviewed-by: Hannes Reinecke <[email protected]>
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: F. Imend?rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG N?rnberg)
On 8/14/2015 2:32 AM, Hannes Reinecke wrote:
> On 08/13/2015 01:50 PM, Johannes Thumshirn wrote:
>> Export the RAW SCSI Inquiry to sysfs as binfile. This way the data can be
>> used by userlang without the need to have and ioctl or use the sg_inq tool.
>>
> userland!
>
Just be careful. There are conditions where this could be stale
data.... LUN reconfig on an array that hasn't been rescanned by the
mid layer yet is such a case.
Any reason you didn't have the sysfs call initiate a lun scan or send an
inquiry so it's always valid data ?
-- james s
On 08/14/2015 02:27 PM, James Smart wrote:
> On 8/14/2015 2:32 AM, Hannes Reinecke wrote:
>> On 08/13/2015 01:50 PM, Johannes Thumshirn wrote:
>>> Export the RAW SCSI Inquiry to sysfs as binfile. This way the
>>> data can be used by userlang without the need to have and ioctl or use the
>>> sg_inq tool.
>>>
>> userland!
>>
>
> Just be careful. There are conditions where this could be stale
> data.... LUN reconfig on an array that hasn't been rescanned by
> the mid layer yet is such a case.
>
> Any reason you didn't have the sysfs call initiate a lun scan or
> send an inquiry so it's always valid data ?
>
Currently the SCSI stack doesn't do LUN rescanning; the only way
to recover from stale data is to remove the device and initiate
a host rescan. That's why we have tools like rescan-scsi-bus.sh etc.
We're working on moving the SCSI stack to do a LUN rescanning, but
that's still future stuff.
So this patch just displays the status quo, without any added
functionality.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: F. Imend?rffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG N?rnberg)