proc_name in sysfs

proc_name in sysfs

[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_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


-- 
Frederic TEMPORELLI
Bull - Echirolles - France

Re: proc_name in sysfs

[Patrick Mansfield]

On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:

> 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

Re: proc_name in sysfs

[Douglas Gilbert]

Patrick Mansfield wrote:
> On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
> 
> 
>>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,
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

Re: proc_name in sysfs

[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)

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.


Douglas Gilbert a écrit :
> Patrick Mansfield wrote:
> 
>> On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
>>
>>
>>> 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,
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Frederic TEMPORELLI
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: proc_name in sysfs

[Douglas Gilbert]

Frederic TEMPORELLI wrote:
> 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

> 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.
> 
> 
> Douglas Gilbert a écrit :
> 
>> Patrick Mansfield wrote:
>>
>>> On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
>>>
>>>
>>>> 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,
>> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: proc_name in sysfs

[Patrick Mansfield]

On Thu, Apr 07, 2005 at 11:06:03AM +1000, Douglas Gilbert wrote:
> Patrick Mansfield wrote:
> >On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
> >
> >
> >>2/ now, how can we get the adapter module name from sysfs ?
> >
> >
> >Why do you need it?


> 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).

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.

> 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.

As an option that sounds nice.

> 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

Re: proc_name in sysfs

[Patrick Mansfield]

On Thu, Apr 07, 2005 at 08:35:16AM +0200, Frederic TEMPORELLI wrote:
> Hi,
> 
> 
> Sorry, no such "driver" directory in /sys/class/scsi_host/hostX/

Doug answered that.

> >>Why do you need it?

If you answer the above you might get better/other suggestions.

-- Patrick Mansfield

Re: proc_name in sysfs

[Christoph Hellwig]

On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
> 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.

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.

Re: proc_name in sysfs

[Frederic TEMPORELLI]

Hi,

Patrick Mansfield a écrit :
> On Thu, Apr 07, 2005 at 08:35:16AM +0200, Frederic TEMPORELLI wrote:
> 
>>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)


> 
>>>>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...


-- 
Frederic TEMPORELLI
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: proc_name in sysfs

[Douglas Gilbert]

Christoph Hellwig wrote:
> On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
> 
>>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.
> 
> 
> 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.

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 .

> Not sure how to proceed forward with this.

Doug Gilbert

Re: proc_name in sysfs

[Christoph Hellwig]

On Fri, Apr 08, 2005 at 06:03:16PM +1000, Douglas Gilbert wrote:
> >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.
> 
> 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 .

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.

Re: proc_name in sysfs

[James Bottomley]

On Mon, 2005-04-11 at 12:52 +0100, Christoph Hellwig wrote:
> 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.

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