State of sg_proc_host_info and sg_proc_hoststrs_info

State of sg_proc_host_info and sg_proc_hoststrs_info

[Christoph Hellwig]

Hi Douglas,

do you know of any users that rely on these functions or rather the
/proc file generated by them?  I plan to rationalize and properly
lock down handling of the scsi host list, and I'd prefer to have
the replacement for scsi_host_get_next() not export to module (sg
is the only user currently).

Re: State of sg_proc_host_info and sg_proc_hoststrs_info

[Douglas Gilbert]

Christoph Hellwig wrote:
> Hi Douglas,
> 
> do you know of any users that rely on these functions or rather the
> /proc file generated by them?  I plan to rationalize and properly
> lock down handling of the scsi host list, and I'd prefer to have
> the replacement for scsi_host_get_next() not export to module (sg
> is the only user currently).

That means dropping this information from sg:

$ cd /proc/scsi/sg/
$ cat host_hdr hosts
uid     busy    cpl     scatg   isa     emul
0       0       3       64      0       0
0       0       5       256     0       1

$ cat host_strs
scsi_debug, Version: 1.64 (20021109), num_devs=9, dev_size_mb=8
SCSI host adapter emulation for IDE ATAPI devices

I put it in in lk 2.4 because the information was
hard to find from the user space. For example a
host (HBA) with no live devices on it was almost
invisible to the user space in lk 2.2

The "host_strs" stuff is available via an ioctl
in the mid-level and is really per driver rather
than per host. Hopefully sysfs will provide similar
information. Will you leave the
/proc/scsi/<driver_name>/host_no information?

The "hosts" stuff (i.e. the numeric data) was useful
to me (at least). The "uid" column was a mistake but
the rest was informative. Most of the data is static
(apart from "busy").

So take it out (along with host_hdr) if it makes life
easier for you.

Doug Gilbert