Nick Lamb wrote: > On Sun, Feb 03, 2002 at 12:52:04PM +0000, Major A wrote: > >>The problem with this is that it is very platform-specific, and, even >>worse, dependent on whether you use devfs or not (in devfs, in the >>long run, major/minor numbers will be assigned dynamically). >> > > I am finding the implicit assumption of this thread hard to believe. > > Why can't you use an ioctl to distinguish SCSI devices from things which > are not SCSI devices? As far as I understood there were already > precautions in place to prevent SANE from grabbing an innocent disk and > thrashing it in the mistaken belief that it is a SCSI scanner. > > e.g. On Linux, sending SCSI_IOCTL_GET_IDLUN to /dev/scanner will have > the effect of either (1) Returning some useless bus layout info which > implies that it is in fact a SCSI scanner or (2) Returning EINVALID > which means it's not a SCSI device.
Nick, Hopefully (1) wouldn't happen and strangely enough case (2) should return ENOTTY (according to Posix/Unix98). Testing for either EINVAL or ENOTTY might be appropriate. > I'm not picking SCSI_IOCTL_GET_IDLUN as special, I'm sure someone who > spends more time up to his/her nick in Linux sg.h will suggest a more > appropriate ioctl, however this is infinitely preferable to looking at > some static list of "special" major/minor numbers. The sg ioctl SG_GET_SCSI_ID yields the same information as SCSI_IOCTL_GET_IDLUN plus the SCSI device type. SANE should be only interested in SCSI device types: - SCANNER (6) - PROCESSOR (3) [HP scanners prefer this type] Just a suggestion ... once SANE spots a SCSI, USB, parport etc. scanner it should hold open a file descriptor to it. If the scanner is hot unplugged you should get a sensible error message next time you try to access it (e.g. ENODEV). By keeping a fd open to a device the module subsystem (or the user) is inhibited from "autocleaning" the module away. If that happens then the next time you open /dev/sg2 (for example) it may not be the scanner you expect it to be! SANE could then have a high level function to rescan for devices. Hooks could also be added so hotplug (and unplug) alerts could be consumed sensibly. A common case would be users power cycling their scanners. Doug Gilbert
