[sane-devel] devfs and scanner detection

[Henning Meier-Geinitz]

Hi,

On Mon, Aug 18, 2003 at 08:25:35AM +0800, Mr E_T wrote:
> Instead of doing a dir listing - why dont you just "stat" the file - if stat
> works then the file exists - else it doesnt.

I tried that first. At least at that time, when calling stat the
kernel tried to load the driver anyway. And that's dead slow when done
multiple times.

I think that's quite logical. Either the kernel does not load the
driver when stat is called. In this case stat is useless, I can use
the directory listing instead. Or stat load the driver (when
available). Then it's slow.

When the delay problem came up I did some tests and stat was as slow
as open. But maybe something has changed since then. Could you try to
stat /dev/usb/scanner0 - /dev/usb/scanner15 for say 100 times and
compare the needed time with opening these files? May kernel currently
doesn't have devfs so I can't test myyself. 

> Hotplugging is ok for devices that get plugged in and out and are required
> straight away. But what about devices that are always plugged in and not always
> used.
> 
> The idea for autoloading of modules is that the driver is loaded when required
> and unloaded other times.

Well, I don't think there is a solution that fits both parties. I (as
a SANE developer) just want a way to check which devices are
available. I can't know if there is a scanner if the kernel doesn't
tell me. And I can't just test for all possible devices beacus that's
too slow.

Have a look at the sane-devel archive, there was some dicussion about
the long delays due to devfs.

> The cups printer driver scans serial, parrallel, usb and scsi by using this
> method and causes the usb printer module to autoload with no great loss of
> speed.

Keep in mind that the SANE backends are individual libraries so every
USB backend scans for the USB devices. We could reduce the amount of
scanning by setting the maximum amount of devices to something lower
than 16 or by not checking /dev/usbscanner* anymore. But that doesn't
solve the basic problem.

Bye,
  Henning