SANE abstraction layer (sanei2)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SANE abstraction layer (sanei2)

Jochen Eisinger
Hi,

recently I thought a bit about sane2 and came to the conclusion that the
next standard should include an abstraction layer, which does not only
abstract the hardware interfaces (like sanei_usb, sanei_scsi, etc..),
but also all other 'features' of the underlying operating system -
basically what sanei is about.

In my opinion, the current sanei has two short-comings:

  1. it doesn't abstract enough parts of the underlying architecture:

  it is not enough to port sanei, if you want to port sane to another
  architecture. a good abstraction layer, however, would allow for
  exactly this.

  2. sanei isn't used consequently by all backends

  there are still backends using libieeee directly instead of using a
  sanei wrapper for it, etc..

I think we should fix these problems with sanei2. The sanei2 would
include not only hardware abstraction, but also a layer that abstracts
the operating system (think of process handling, but also of config file
 paths etc). And, it should be mandatory to use sanei provided functions.

This has several advantages. First of all, using a unified interface for
access to devices, configuration files, etc.. perhaps allows for a
decent configuration tool (finally) Next, porting sane to another
architecture should be relatively easy, given a c compiler, a basic libc
and a ported version of sanei.

Anyway, I'd suggest to include the following for big interfaces into sanei2:

1. Hardware interfaces (SCSI/USB/PP/(serial?))
2. Operating system (file locking, process management, ipc, dll loading,
(networking?))
3. Configuration (config files, firmware files, calibration data)
4. Core functions (image formats (like jpeg), auth, debug output, stuff
like constrain_value, maybe encryption?)

If I'm not mistaken, these functions should be enough to write a sane
backend that will run on any architecture for which sanei2 exists,
without the need to modify the source of the sane backend.

maybe a short teaser at the end: think about having a stable sane
abstraction layer for win32, packaged as a .dll under some maybe
lgpl-like license. A scanner vendor could then write SANE2 compliant
scanner drivers (possibly still with a TWAIN frontend, implementing
their own version of the sane2 interface, which is public domain) and
using our sanei2.dll for accessing the hardware. The vendor would get
for free (a) support for his scanner on various win32 versions and (b)
support for his scanner on various other operating systems, without
having to change the source. even a binary only backend for linux would
be possible.

comments? :)

kind regards
-- jochen

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE abstraction layer (sanei2)

Enrico Weigelt, metux IT service
* Jochen Eisinger <[hidden email]> schrieb:

hi,

> recently I thought a bit about sane2 and came to the conclusion that the
> next standard should include an abstraction layer, which does not only
> abstract the hardware interfaces (like sanei_usb, sanei_scsi, etc..),
> but also all other 'features' of the underlying operating system -
> basically what sanei is about.

What things exactly do you have in mind ?

<snip>

> In my opinion, the current sanei has two short-comings:
>
>   1. it doesn't abstract enough parts of the underlying architecture:
>
>   it is not enough to port sanei, if you want to port sane to another
>   architecture. a good abstraction layer, however, would allow for
>   exactly this.

Please more in detail ?

If you think about interfaces - these are normally jobs for other
libs, ie. usb handling is AFAIK done by libusb.

For parport stuff we could just write an libparport (but please,
please also as an separate project like libusb is) and we're done
at this part. (of course someone will have to port libparport)

<snip>

> I think we should fix these problems with sanei2. The sanei2 would
> include not only hardware abstraction, but also a layer that abstracts
> the operating system (think of process handling, but also of config file
> paths etc). And, it should be mandatory to use sanei provided functions.

heh ?! you wanna put process control stuff into sanei ?
can't we just rely on posix and require an proper libc on all systems ?

<snip>
 
> Anyway, I'd suggest to include the following for big interfaces into sanei2:
>
> 1. Hardware interfaces (SCSI/USB/PP/(serial?))

Should be done by separate libs, as already done by libusb.
These things are not only interesting for sane, but for many other
projects. We shouln't give away the opportunity to concentrate efforts.

<snip>

> 2. Operating system (file locking, process management, ipc, dll loading,
> (networking?))

File locking: what's wrong with the flock() api ?
Process mgt: what's wrong w/ posix ?
IPC: isn't there an universal lib for that ? otherwise let's
                invent some. of course as a separate project.
dll-loading: libdl ?
networking: bsd socket api should be available on all interesting
                systems, or if not should be *made* available.
               
> 3. Configuration (config files, firmware files, calibration data)

Whats platform dependent here ?

> 4. Core functions (image formats (like jpeg), auth, debug output, stuff
> like constrain_value, maybe encryption?)

Image encoding is not the job of the sane core. libjpeg will do this fine.
If we wanna support multiple format, we should choose an suitable
wrapper library (ie. something like gdk-pixbuf, but w/o glib bloat)

<snip>

> maybe a short teaser at the end: think about having a stable sane
> abstraction layer for win32, packaged as a .dll under some maybe
> lgpl-like license. A scanner vendor could then write SANE2 compliant
> scanner drivers (possibly still with a TWAIN frontend, implementing
> their own version of the sane2 interface, which is public domain) and
> using our sanei2.dll for accessing the hardware. The vendor would get
> for free (a) support for his scanner on various win32 versions and (b)
> support for his scanner on various other operating systems, without
> having to change the source. even a binary only backend for linux
> would be possible.

And you wanna allow them to poison the sane world w/ proprietary drivers ?

I'm absolutely against this. Almost for the same reasons why I'm
against proprietary kernel modules.

a) security reason: never trust an binary. you've got no chance to
                        know comes on board.
                       
b) technical reason: binary stuff fits only rarely on such flexible
                        and thus differing systems like GNU/Linux
                        (I consider the lack of an constant ABI as an
                        big advantage) do not work reliably. Either you
                        have to make too many restrictions on the target
                        systems (ie. runs on some major distros, but
                        not on self-compiled stuff) or the vendors had
                        to supply countless of different builds.

c) social reason: the availability of ready-to-click (TM) drivers
                        reduces the preasure on the hardware vendors to
                        open specs to the opensource community. today
                        GNU/Linux users choose their scanners by sane's
                        compatibility list. unsupported products simply
                        cannot be sold to (continously growing) penguin
                        folks. this provides some kind of market cleanup.
                        the oss community has proven much more reliability
                        and better support on hardware drivers (as long
                        as specs are open) than propiertary stuff will
                        ever have. I'm not happy with the idea to open
                        doors for poisoning our software quality with
                        proprietary shit when preasure is taken away.
                       
BTW: if it goes so far that (technically) stupid ABI layers are
fizzed in (as already seen on several kernel drivers, which of
course aren't part of the offical tree for very good reason),
just to make it easier for proprietary stuff, this will be the
day when I'll do a forkoff removing this shit again.


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [hidden email]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SANE abstraction layer (sanei2)

Gerhard Jäger
Good morning ;)

On Wednesday 19 October 2005 23:38, Enrico Weigelt wrote:

> * Jochen Eisinger <[hidden email]> schrieb:
>
> hi,
>
> > recently I thought a bit about sane2 and came to the conclusion that the
> > next standard should include an abstraction layer, which does not only
> > abstract the hardware interfaces (like sanei_usb, sanei_scsi, etc..),
> > but also all other 'features' of the underlying operating system -
> > basically what sanei is about.
>
> What things exactly do you have in mind ?
>
> <snip>
>
> > In my opinion, the current sanei has two short-comings:
> >
> >   1. it doesn't abstract enough parts of the underlying architecture:
> >
> >   it is not enough to port sanei, if you want to port sane to another
> >   architecture. a good abstraction layer, however, would allow for
> >   exactly this.
>
> Please more in detail ?
>
> If you think about interfaces - these are normally jobs for other
> libs, ie. usb handling is AFAIK done by libusb.

Guess this stuff is already done, either by such libs as libusb, glibc
or systemlibs on other systems.

>
> For parport stuff we could just write an libparport (but please,
> please also as an separate project like libusb is) and we're done
> at this part. (of course someone will have to port libparport)

Already done too. Either libieee1248 or for sane: sanei_pp which
tries to do excactly what Jochen wants to have.

> <snip>
>
> > I think we should fix these problems with sanei2. The sanei2 would
> > include not only hardware abstraction, but also a layer that abstracts
> > the operating system (think of process handling, but also of config file
> > paths etc). And, it should be mandatory to use sanei provided functions.
>
> heh ?! you wanna put process control stuff into sanei ?
> can't we just rely on posix and require an proper libc on all systems ?

I think in the end we've already started that, for the hw-interfaces we
have the sanei_usb, sanei_pp, sanei_scsi.

Also for system stuff like fork/threads we have sanei_thread, for locking
I tried to introduce sanei_access

>
> <snip>
>  
> > Anyway, I'd suggest to include the following for big interfaces into sanei2:
> >
> > 1. Hardware interfaces (SCSI/USB/PP/(serial?))
>
> Should be done by separate libs, as already done by libusb.
> These things are not only interesting for sane, but for many other
> projects. We shouln't give away the opportunity to concentrate efforts.

See my comments above - we have this stuff!

> <snip>
>
> > 2. Operating system (file locking, process management, ipc, dll loading,
> > (networking?))
>
> File locking: what's wrong with the flock() api ?
> Process mgt: what's wrong w/ posix ?
> IPC: isn't there an universal lib for that ? otherwise let's
> invent some. of course as a separate project.
> dll-loading: libdl ?
> networking: bsd socket api should be available on all interesting
> systems, or if not should be *made* available.

Guess we need to do some work here, as we want to cover and probably
work around the various incarnations of i.e. POSIX. Also the locking
stuff.

> > 3. Configuration (config files, firmware files, calibration data)
>
> Whats platform dependent here ?

Nothing, but we have no common format for config files. FW and calibration
is not that important, as each backend has to handle its format. But the
config stuff should be common. Has been discussed before.

> > 4. Core functions (image formats (like jpeg), auth, debug output, stuff
> > like constrain_value, maybe encryption?)
>
> Image encoding is not the job of the sane core. libjpeg will do this fine.
> If we wanna support multiple format, we should choose an suitable
> wrapper library (ie. something like gdk-pixbuf, but w/o glib bloat)
>
> <snip>
>
> > maybe a short teaser at the end: think about having a stable sane
> > abstraction layer for win32, packaged as a .dll under some maybe
> > lgpl-like license. A scanner vendor could then write SANE2 compliant
> > scanner drivers (possibly still with a TWAIN frontend, implementing
> > their own version of the sane2 interface, which is public domain) and
> > using our sanei2.dll for accessing the hardware. The vendor would get
> > for free (a) support for his scanner on various win32 versions and (b)
> > support for his scanner on various other operating systems, without
> > having to change the source. even a binary only backend for linux
> > would be possible.
>
> And you wanna allow them to poison the sane world w/ proprietary drivers ?

Ain't this already done?

> I'm absolutely against this. Almost for the same reasons why I'm
> against proprietary kernel modules.
>
> a) security reason: never trust an binary. you've got no chance to
> know comes on board.

Hmmm, don't wanna start a flameware, but I'm pretty sure a lot of users
won't care about that. They wan't to use their devices.

> b) technical reason: binary stuff fits only rarely on such flexible
> and thus differing systems like GNU/Linux
> (I consider the lack of an constant ABI as an
> big advantage) do not work reliably. Either you
> have to make too many restrictions on the target
> systems (ie. runs on some major distros, but
> not on self-compiled stuff) or the vendors had
> to supply countless of different builds.

Nope - see Nvidia, or at least the binary only stuff from EpKowa. The
vendors need to provide some objects/libs which could be used...
AFAIK, Lexmark and Brother also started such a thing...

> c) social reason: the availability of ready-to-click (TM) drivers
> reduces the preasure on the hardware vendors to
> open specs to the opensource community. today
> GNU/Linux users choose their scanners by sane's
> compatibility list. unsupported products simply  
> cannot be sold to (continously growing) penguin
> folks.

In an ideal world...

> this provides some kind of market cleanup.
> the oss community has proven much more reliability
> and better support on hardware drivers (as long
> as specs are open) than propiertary stuff will
> ever have. I'm not happy with the idea to open
> doors for poisoning our software quality with
> proprietary shit when preasure is taken away.
>
> BTW: if it goes so far that (technically) stupid ABI layers are
> fizzed in (as already seen on several kernel drivers, which of
> course aren't part of the offical tree for very good reason),
> just to make it easier for proprietary stuff, this will be the
> day when I'll do a forkoff removing this shit again.

Oh boy, don't even think about that ;) How would you call that
project: YAS (Yet Another SANE) ;)

On a lot of points I think we already have more or less what
Jochen suggests. We'd like to cover a great variety of systems
and HW buses. And therefore we need to a certain point these
abstraction layers - simply to fixup the differences and make the
underlying stuff behave the same on each OS we'd like to support.

Ciao,
Gerhard



--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Loading...