[sane-devel] All sane frontends segfault with my HP 5200C

Douglas Gilbert dgilbert at interlog.com
Sun Feb 3 18:06:12 GMT 2002


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









More information about the sane-devel mailing list