proc_name in sysfs
Hello,
We are using HBAs modules names from "proc_name" interface in sysfs:/sys/class/scsi_host/hostX/proc_name.
But with new Emulex drivers (8.0.21 and +), proc_name is reporting <NULL> (previous drivers were reporting "lpfc").
=> In the driver code, .proc_name field from scsi_host_template structure is no more initialized.
James Smart told us that the "removal" of .proc_name field (not really removed, but no more initialized) was part of the /proc interfaces removal (suggested by scsi-linux feedback).
So:
1/ now, what is the aim of proc_name interface (reporting "<NULL>") in sysfs ? 2/ now, how can we get the adapter module name from sysfs ?
=> I'm just thinking that .proc_name field has to be kept initialized and/or something has to be changed to replace the confusing "proc" prefix.
Best regards
Signature · 2 lines
Frederic TEMPORELLI Bull - Echirolles - France
Quoted 1 line · Frederic TEMPORELLI
2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0] qla1280 [1] qla1280 [2] qla2xxx [3] qla2xxx
Or, script it:
[elm3b79 tmp]$ more xx.sh
#! /bin/sh
hdir=/sys/class/scsi_host
for i in ${hdir}/host*
do
host_dir=$(cd ${i}/device;/bin/pwd)
driver_dir=$(cd ${host_dir}/../driver;/bin/pwd)
module=$(basename ${driver_dir})
# echo ${i} is in: ${host_dir}
echo "${i} module (driver) is: ${module}"done
[elm3b79 tmp]$ sh ./xx.sh /sys/class/scsi_host/host0 module (driver) is: qla1280 /sys/class/scsi_host/host1 module (driver) is: qla1280 /sys/class/scsi_host/host2 module (driver) is: qla2300 /sys/class/scsi_host/host3 module (driver) is: qla2300
-- Patrick Mansfield
Quoted 30 lines · Patrick Mansfield
Quoted 1 line · Frederic TEMPORELLI
2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0] qla1280 [1] qla1280 [2] qla2xxx [3] qla2xxxOr, script it:
[elm3b79 tmp]$ more
xx.sh
#!/bin/shhdir=/sys/class/scsi_host
for i in ${hdir}/host*
dohost_dir=$(cd ${i}/device;/bin/pwd) driver_dir=$(cd ${host_dir}/../driver;/bin/pwd) module=$(basename ${driver_dir}) # echo ${i} is in: ${host_dir} echo "${i} module (driver) is: ${module}"
Quoted 7 lines
done
[elm3b79 tmp]$ sh ./xx.sh
/sys/class/scsi_host/host0module (driver) is: qla1280/sys/class/scsi_host/host1module (driver) is: qla1280/sys/class/scsi_host/host2module (driver) is: qla2300/sys/class/scsi_host/host3module (driver) is: qla2300
Patrick,
lsscsi currently uses proc_name so it needs to be changed to use the above logic (if LLDs are going to stop populating proc_name).
It has been suggested that I extend lsscsi to show transport info (as seen from the HBA) found in the various *_transport directories in sysfs.
Also I have been thinking about ways to list less tha all scsi devices. For example: "lsscsi 1:0:3:0" to look at one device and "lsscsi 1:-" for all scsi devices hanging off host1. I'm not sure whether "lsscsi /dev/sda" is a good idea. Any suggestions?
Doug Gilbert
Hi,
Sorry, no such "driver" directory in /sys/class/scsi_host/hostX/ (checked: Emulex "lpfc" 8.0.24 and LSI "mptscsih" 3.01.18)
note: there's also a "proc_name" interface for LSI "mtpscsih", located in /sys/class/scsi_host/hostX/, which is reporting "mptscsih" string.
Any other ideas ?
Best regards.
Quoted 63 lines · Douglas Gilbert
Quoted 31 lines · Patrick Mansfield
Quoted 1 line · Frederic TEMPORELLI
2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0] qla1280 [1] qla1280 [2] qla2xxx [3] qla2xxxOr, script it:
[elm3b79 tmp]$ more
xx.sh
#!/bin/shhdir=/sys/class/scsi_host
for i in ${hdir}/host*
dohost_dir=$(cd ${i}/device;/bin/pwd) driver_dir=$(cd ${host_dir}/../driver;/bin/pwd) module=$(basename ${driver_dir}) # echo ${i} is in: ${host_dir} echo "${i} module (driver) is: ${module}"Quoted 7 lines
done
[elm3b79 tmp]$ sh ./xx.sh
/sys/class/scsi_host/host0module (driver) is: qla1280/sys/class/scsi_host/host1module (driver) is: qla1280/sys/class/scsi_host/host2module (driver) is: qla2300/sys/class/scsi_host/host3module (driver) is: qla2300Patrick,
lsscsi currently usesproc_nameso it needs to be changed to use the above logic (if LLDs are going to stop populatingproc_name).It has been suggested that I extend lsscsi to show transport info (as seen from the HBA) found in the various
*_transportdirectories in sysfs.Also I have been thinking about ways to list less tha all scsi devices. For example: "lsscsi 1:0:3:0" to look at one device and "lsscsi 1:-" for all scsi devices hanging off host1. I'm not sure whether "lsscsi
/dev/sda" is a good idea. Any suggestions?Doug Gilbert
-
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
Signature · 5 lines
Frederic TEMPORELLI - 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
Quoted 5 lines · Frederic TEMPORELLI
Hi,
Sorry, no such "driver" directory in
/sys/class/scsi_host/hostX/(checked: Emulex "lpfc" 8.0.24 and LSI "mptscsih" 3.01.18)
I may have missed the point here. Are you talking about Patrick's shell script? It sort of works for me. Example:
$ ./scan_hosts.sh /sys/class/scsi_host/host0 module (driver) is: mptbase /sys/class/scsi_host/host1 module (driver) is: mptbase /sys/class/scsi_host/host2 module (driver) is: mptbase /sys/class/scsi_host/host3 module (driver) is: mptbase /sys/class/scsi_host/host4 module (driver) is: qla2300 /sys/class/scsi_host/host5 module (driver) is: qla2300 $ lsscsi -H [0] mptscsih [1] mptscsih [2] mptscsih [3] mptscsih [4] qla2xxx [5] qla2xxx
Note that the module name and the proc_name are different! It looks like Patrick's script gives the module name "closest" to the PCI bus while proc_name gives the "upper" lower level driver name :-)
BTW "/bin/pwd" gives a different result to "pwd"
in a bash shell just after a symlink has been
followed.
Doug Gilbert
Quoted 69 lines
note: there's also a "
proc_name" interface for LSI "mtpscsih", located in/sys/class/scsi_host/hostX/, which is reporting "mptscsih" string.Any other ideas ?
Best regards.
Quoted 60 lines · Douglas Gilbert
Quoted 32 lines · Patrick Mansfield
Quoted 1 line · Frederic TEMPORELLI
2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0] qla1280 [1] qla1280 [2] qla2xxx [3] qla2xxxOr, script it:
[elm3b79 tmp]$ more
xx.sh
#!/bin/shhdir=/sys/class/scsi_host
for i in ${hdir}/host*
dohost_dir=$(cd ${i}/device;/bin/pwd) driver_dir=$(cd ${host_dir}/../driver;/bin/pwd) module=$(basename ${driver_dir}) # echo ${i} is in: ${host_dir} echo "${i} module (driver) is: ${module}"Quoted 7 lines
done
[elm3b79 tmp]$ sh ./xx.sh
/sys/class/scsi_host/host0module (driver) is: qla1280/sys/class/scsi_host/host1module (driver) is: qla1280/sys/class/scsi_host/host2module (driver) is: qla2300/sys/class/scsi_host/host3module (driver) is: qla2300Patrick,
lsscsi currently usesproc_nameso it needs to be changed to use the above logic (if LLDs are going to stop populatingproc_name).It has been suggested that I extend lsscsi to show transport info (as seen from the HBA) found in the various
*_transportdirectories in sysfs.Also I have been thinking about ways to list less tha all scsi devices. For example: "lsscsi 1:0:3:0" to look at one device and "lsscsi 1:-" for all scsi devices hanging off host1. I'm not sure whether "lsscsi
/dev/sda" is a good idea. Any suggestions?Doug Gilbert
-
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
Quoted 4 lines · Frederic TEMPORELLI
Hi,
Sorry, no such "driver" directory in
/sys/class/scsi_host/hostX/
Doug answered that.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Why do you need it?
If you answer the above you might get better/other suggestions.
-- Patrick Mansfield
Hi,
Quoted 10 lines · Patrick Mansfield
Quoted 4 lines · Frederic TEMPORELLI
Hi,
Sorry, no such "driver" directory in
/sys/class/scsi_host/hostX/Doug answered that.
thx, I've just try the script and it works... (mea culpa, I should have look in details to the symlinks)
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Why do you need it?
If you answer the above you might get better/other suggestions.
We already have scripts for getting HBAs informations, and these scripts are based on /sys/class/scsi_host/hostX/proc_name to define how to process informations (we don't care about WWPN when using U320 adapter).
=> I'll change our scripts according to Doug's solution, this should be fine.
Thanks again...
Signature · 5 lines
Frederic TEMPORELLI - 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
Quoted 7 lines · Douglas Gilbert
Quoted 6 lines · Patrick Mansfield
Quoted 1 line · Frederic TEMPORELLI
2/ now, how can we get the adapter module name from sysfs ?
Quoted 7 lines
Quoted 1 line
Why do you need it?
Patrick,
lsscsi currently usesproc_nameso it needs to be changed to use the above logic (if LLDs are going to stop populatingproc_name).
Oops, I didn't notice, I had assumed it was using the sysfs layout.
Yes, seems like it should use the sysfs driver info, proc_name is rather useless in sysfs context.
Quoted 3 lines
It has been suggested that I extend lsscsi to show transport info (as seen from the HBA) found in the various
*_transportdirectories in sysfs.
As an option that sounds nice.
Quoted 5 lines
Also I have been thinking about ways to list less tha all scsi devices. For example: "lsscsi 1:0:3:0" to look at one device and "lsscsi 1:-" for all scsi devices hanging off host1. I'm not sure whether "lsscsi
/dev/sda" is a good idea. Any suggestions?
Sounds good, but maybe not (directly) for /dev. udevinfo can supply that, it has a /dev to /sys mapping:
[elm3b79 patman]$ udevinfo -q path -n /udev/mydisk-sdag /block/sdm
-- Patrick Mansfield
Quoted 14 lines · Frederic TEMPORELLI
Hello,
We are using HBAs modules names from "
proc_name" interface in sysfs:/sys/class/scsi_host/hostX/proc_name.But with new Emulex drivers (8.0.21 and +),
proc_nameis reporting <NULL> (previous drivers were reporting "lpfc").
=> In the driver code, .proc_name field fromscsi_host_templatestructure is no more initialized.
James Smart told us that the "removal" of .proc_name field (not really removed, but no more initialized) was part of the /proc interfaces removal (suggested by scsi-linux feedback).
Quoted 7 lines
So:
1/ now, what is the aim ofproc_nameinterface (reporting "<NULL>") in sysfs ?
2/ now, how can we get the adapter module name from sysfs ?=> I'm just thinking that .proc_name field has to be kept initialized and/or something has to be changed to replace the confusing "proc" prefix.
The real problem is that someone decided to export the proc_name in sysfs. It's supposed to be only procfs-specific but someone violated that rule.
Not sure how to proceed forward with this.
Quoted 16 lines · Christoph Hellwig
Quoted 14 lines · Frederic TEMPORELLI
Hello,
We are using HBAs modules names from "
proc_name" interface in sysfs:/sys/class/scsi_host/hostX/proc_name.But with new Emulex drivers (8.0.21 and +),
proc_nameis reporting <NULL> (previous drivers were reporting "lpfc").
=> In the driver code, .proc_name field fromscsi_host_templatestructure is no more initialized.
James Smart told us that the "removal" of .proc_name field (not really removed, but no more initialized) was part of the /proc interfaces removal (suggested by scsi-linux feedback).So:
1/ now, what is the aim ofproc_nameinterface (reporting "<NULL>") in sysfs ? 2/ now, how can we get the adapter module name from sysfs ?
Quoted 5 lines
Quoted 1 line
=> I'm just thinking that .proc_name field has to be kept initialized and/or something has to be changed to replace the confusing "proc" prefix.
The real problem is that someone decided to export the
proc_namein sysfs. It's supposed to be only procfs-specific but someone violated that rule.
Forget the "proc_" part. It is effectively the lld_name.
Allowing the LLD to name itself to the scsi subsystem makes sense, especially when the LLD is made up of several kernel modules. See my previous example comparing the output of lsscsi -H and scan_host.sh .
Quoted 1 line
Not sure how to proceed forward with this.
Doug Gilbert
Quoted 9 lines · Douglas Gilbert
Quoted 2 lines
The real problem is that someone decided to export the
proc_namein sysfs. It's supposed to be only procfs-specific but someone violated that rule.Forget the "
proc_" part. It is effectively thelld_name.Allowing the LLD to name itself to the scsi subsystem makes sense, especially when the LLD is made up of several kernel modules. See my previous example comparing the output of lsscsi -H and
scan_host.sh.
In theory we have ->name for that, but people have decided to put really verbose stuff in there. A module name is important, not just for scsi.
James once had a proposal where the scsi_host can link to the module in sysfs, which is the right thing and needed for other things like mkinitrd aswell.
Quoted 3 lines · Christoph Hellwig
James once had a proposal where the
scsi_hostcan link to the module in sysfs, which is the right thing and needed for other things like mkinitrd aswell.
The code is actually in. Taking advantage of it is slightly more complex than I anticipated. I'll dig out the patches I had for sym2 to do it.
James