[sane-standard] SANE 2 driver suggestion

[m. allan noah]

On 2/17/07, Donald Straney <burntfuse at gmail.com> wrote:
> 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.

these detection systems are relatively similar probing, across all OS's
that sane supports. while i agree that they are archaic, they are easily
abstracted into 'hunt thru scsi bus for X' and 'hunt thru usb bus for Y'.
doing linux differently would require some sort of backend registration
mechanism that we do not currently have.

> 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.

and kernel space drivers are a whole new kettle of fish. sane has
slowly abandoned its earlier kernel-level driver in favor of a user-land
solution, which has been historically favored by all kernel devels. Has
the situation on LKML suddenly changed to become favorable to large
chunks of code for low-speed devices (like scanners) becoming kernel
modules again?

> 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.

this point presumes that 'HAL support' is a good thing, without explaining
why. to a certain extent, sane devels are a wide-ranging group, and dont
spend much time keeping up with everything new in Linux-only land. :)

> 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.

so you are saying that someone who writes a front-end for sane would have
to use /dev/ io on linux, but continue to link to libsane elsewhere?

>  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.

i agree with the basic idea of making backends as simple as possible,
but i dont think your abstraction of 'changing the drivers responsibilities'
is detailed enough to do any real work. can you make more specific
suggestions as to how you would structure the API?

> 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.

ok, this answers my question above. break sane into two parts (or 3?)
and use the device node as the go-between. most front-ends will
link with libsane.

  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.

and now we've got two api's to manage? can you suggest how you
would structure the ioctl's or whatever the kernel-level interface will
be? i am concerned about how you would provide to your dbus code
the level of device-specific control that the sane options functions
provide...

i feel that we are discussing a solution without having a firm
statement of the problem. this keeps coming up, so there must be
some sort of need here, but i dont have a concise statement of the
issue. can you help?

allan