[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