[sane-standard] SANE 2 driver suggestion

[Donald Straney]

Hi,

I've got a suggestion for the drivers in the upcoming SANE 2 - it
would probably be more efficient if they were put in kernel space, at
least for Linux 2.6.  With udev and the new driver model, the 2.6
kernel has a great hardware detection system already in place, and
SANE could take advantage of that for hotplug detection and all the
other features.  Before, SANE has had to implement its own device
detection system, which can be inefficient in some cases.  For
example, I'm working on a daemon which would provide a D-BUS image
capture service by interfacing to SANE, and to detect hotplugged
scanners while it's running, it has to call sane_get_device_list and
rebuild its entire internal device list (which has to be current so it
can poll for button presses) each time HAL issues a hotplug event.
Besides, each driver has to probe for the device itself.  With
kernel-space drivers, each one could just register a list of bus IDs
or a probe function (for parallel port devices) so it could be
automatically inserted when needed, instead of having to call the
probe function for every single registered driver just to get a device
list.  Another good point is that HAL could then handle scanners
easily, without having to build any HAL integration into SANE, just a
few HAL rules which register a "scanner" or "image capture" capability
for the devices.

To not kill portability, the wrapper around the drivers could be
expanded as necessary.  The interface to the actual driver code could
be kept high-level, so that on Linux, I/O would be done through a
device node, and on other systems (like Windows and OS X) where each
driver would be built as a library, it could be done through a buffer
the way it's done now.  The same goes for options - on Linux, the
wrapper would accept ioctl operations and pass them on to the driver,
and on other systems the wrapper could just take the arguments from a
library function.  Of course, some things like memory allocation and
copying between user space and kernel space work differently in kernel
drivers than in libraries, but if the wrapper was well written, it
could take care of that.  A "sanei_malloc" function could call kmalloc
when built on Linux, and the system's malloc when built on other
systems, and the wrapper could also handle any transfer of data
between the program and the driver.  For registering drivers, the
wrapper could either pass on the bus IDs to the kernel's driver model
(in Linux) or have its own probe functions on the systems where it's
built as a library.

Of course, kernel programming is VERY different from userspace
programming, but what I'm thinking about is changing the drivers'
responsibilities from doing most of the communication to just issuing
device-specific commands, and letting the wrapper handle most of the
real work.  That way, each driver would be simple enough that it would
be almost more like a script for the wrapper to run than a stand-alone
piece of code.  The libgphoto2 backend wouldn't work with in-kernel
drivers, but honestly, it wasn't that useful anyways.

The userspace access to the devices would have to be abstracted a bit
more too.  The dll backend would be replaced with a single libsane
which scanning programs would link to.  On Linux,  libsane would
contain the functions to manipulate the device nodes, and on other
systems, it would load and use the functions from the other driver
libraries.  Of course, a program which wants to interface with SANE at
a lower level to handle hotplugging better, like my D-BUS image
capture daemon, could just talk to the device nodes directly.  I know
that all of this could be a lot of work, but I think it would be worth
it to have better Linux support.

Any suggestions? Comments? Reasons why this is a bad idea?

Donald Straney