[paranoia] No generic SCSI device found

[Douglas Gilbert]

Dale E Martin wrote:
> 
> > If this is a concern, devfs in lk 2.4 might be considered.
> > The "primary" scsi device nodes look like this:
> > $ cd /dev/scsi/host3/bus0/target4/lun0/
> > $ ls -l *
> > brw-------    1 dougg    disk      11,   0 Dec 31  1969 cd
> > crw-rw-rw-    1 root     root      21,   2 Dec 31  1969 generic
> >
> > >From this we know that on scsi host number 3, bus 0,
> > target 4, lun 0 there is a cdrom. Permissions can
> > then be set on these primary device nodes.
> > The /dev/sr0 and /dev/sg2 names are still there if the
> > default configuration of the devfs daemon (devfsd) is
> > used. However they are symbolic links to the "primary"
> > device nodes. Something like cdparanoia can do a
> > different type of device scan now, based on a directory
> > scan below /dev/scsi (or perhaps /dev/ide).
> 
> Interesting that this comes up now.  Over the weekend I wrote a patch for
> cdparanoia to scan the /devfs filesystem looking for drives (it's at
> "http://www.cliftonlabs.com/~dmartin/debian" - there's a diff in there
> along with a Debian source and binary package.)
> 
> Anyways, I had it scanning for "generic" but you're saying it should scan
> for "cd", correct?  That makes more sense now that I think about it.

Dale,
The 'cd' and 'generic' entries are controlled by the
sr and sg drivers respectively. If neither driver is
loaded then that directory (and perhaps a few above
it) probably won't be there.

The presence of the 'cd' entry tells you that sr is
loaded/built in and the scsi type of that device is
"ROM" or "WORM". This makes it a potentially interesting 
device for cdparanoia.

Since the sg driver accepts all SCSI devices, then for
the purposes of devfs directory scanning, loading sg
as a module (or building it in) may be useful. For
example scanners will only appear as 'generic' entries
(since the sd, sr, st and osst drivers are not interested).

The output of 'cat /proc/scsi/scsi' is derived from the
SCSI mid level, so it should be visible even if no upper
level drivers (i.e. sd, sr, st, osst or sg) are loaded.
Still, /proc/scsi/scsi is ugly to parse. Various entries
in /proc/scsi/sg/* are designed to be easier to scan but
again they require sg to be loaded/built in.

Thanks for the code. I plan to enhance my sg_utils package
with a devfs based scsi scan.

Doug Gilbert

--- >8 ----
List archives:  http://www.xiph.org/archives/
Paranoia homepage: http://www.xiph.org/paranoia/
To unsubscribe from this list, send a message to 'paranoia-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.