Re: [PATCH] scsi-misc-2.5 remove scsi_scan.c EVPD code

[Douglas Gilbert <dougg@torque.net>]

Patrick Mansfield wrote:
> On Mon, May 05, 2003 at 10:46:02AM -0700, Mike Anderson wrote:
> 
>>Patrick Mansfield [patmans@us.ibm.com] wrote:
> 
> 
>>>Right now, we could have an sgid that runs whenever an sg is found (sg
>>>hotplug generated via device_register), and stores a sysfs path and the id
>>>returned into a flat file.
>>
>>I believe devlabel's scsi_unique_id.c file does some of this, though I
>>have not looked at it closely.
>>
>>-andmike
> 
> 
> Yes, it looks very close, and has the underlying infrastructure (uses the
> SCSI_IOCTL_SEND_COMMAND, not sg, so can be used for all upper level linux
> scsi devices). It looks like we would need functionallity that is in the
> devlabel script itself (to output just a  single ID), maybe just integrate
> that into scsi_unique_id. (I did not look closely at devlabel, it has more
> lines than the scsi_unique_id.c source.)

Patrick,
Even if you don't use sg you still have to use
the appropriate upper level driver and cope with its
vagaries (e.g. does it need O_NONBLOCK, could it
lock you out with O_EXCL). Also you need a device
file node to open: it may not be there (devfs helps
here) or could have some tricky symlink.

IMO a safe way to work for disks in lk 2.5 would be to
scan /sys/block, apply some heuristic to filter out
degenerate devices, make your own device node (i.e. mknod)
open it and use the SG_IO ioctl on that fd, etc.
This method needs root privelege.

> It looks like scsi_unique_id should also dump the code set, so it can pick
> one code set (the same one) over anoother (if both were ever used by a
> single LU).
> 
> It fails for character devices, but that is easily fixed by deletion of
> the check (SCSI_IOCTL_SEND_COMMAND works for any scsi device: st, sd, sr
> or sg). I deleted the check and it ran ok on a "processor" scsi device,
> though the device does not support page 80 or page 83. 
> 
> scsi_unique_id should also have some sort of error checking/reporting, so
> we can tell if a device is not functioning (versus does not support page
> 80 or 83).
> 
> I don't know how this would be integrated into the scsi device model tree,
> given the current flux (class or bus for upper level devices, as well as
> for the scsi_device itself).

Another approach could be to have a device node for
the scsi mid level (e.g. /dev/scsi) with an ioctl
that takes a device's toplogical address and some
parameters (e.g. VPD_83) and yields the response
of that INQUIRY (or yields an scsi status and a
sense buffer).

Doug Gilbert