Comment on "Making Hardware Just Work"

[David Zeuthen]

On Wed, 2003-09-17 at 13:26, Nicolai Haehnle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I originally sent this to Havoc Pennington in response to the article at 
> http://ometer.com/hardware.html
> He suggested that I should send it here, so here goes...
> 
> (text of original mail follows)
> I think that you're generally on the right track with the ideas in that
> article. There's one thing I'd like to mention though, about the way device
> functionality is accessed.
> 
> Instead of defining the functionality of a device in terms of its general
> type, it could be defined in terms of interfaces.
> There would be a basic interface for enabling/disabling a device that
> virtually every device supported.
> A plain old CD-ROM drive would support a "filesystem" interface and an
> "eject/load" interface on top of that. A CDR would also support a "burn"
> interface.
> Now the digital camera would support the "filesystem" interface, too (it
> should be clear now where the idea for interfaces comes from). This could
> allow all sorts of nice things, e.g. one could browse the photos on the
> digital camera using any image-aware desktop application without explicitly
> downloading them.
> The digital camera could also support aninterface to control the camera
> functions directly, i.e. trigger the camera via PC software.
> 
> These interfaces also lend themselves to a very straightforward (IMHO) API.
> Basically, there's a function to list the interface types a device supports
> (perhaps returned as an array of strings, or a string with whitespace
> seperated tokens).
> 
> Every interface then defines its own entry point(s) to provide access to
>  its functionality.
> 
> This could be done in a way that is very similar to the way OpenGL or X
> extensions are implemented.
> 

Hi Nicolai,

I think this is a very good angle - it's something I have not given much
thought yet in my draft spec [1]. My ideas on this (not documented in my
draft spec yet) was something along the lines of

 1. use libhal to find the device you're interested in and get
    the device unique id

 2. use some appropriate device support library that knows what a
    libhal device unique id is
    (note: the appropriate device support library would use hw /
     bus specific information stored as properties to interact
     with the device through the OS and possibly /dev files)

Now this requires the application programmer to be aware of the
different device support libraries out there and link with them. Not
good.

Assuming we integrate your ideas with my spec and implementation, which
I'm 110% for, the process would be something along the lines of

 1. use libhal to find the device you're interested in

 2. get a list of interfaces

 3. use these interfaces as appropriate

Hey, presto: The application wouldn't need to know anything about
support libraries at all. Nice.

For specific use with non-existing interfaces (we might not define the
interface to talk to a fridge as the first thing), the application could
always do as in the scenario above with giving the libhal unique device
id to some library.

Now, what would the issues we need to solve be:

 1. Define the interfaces
    your mail already shows this is possible since most devices
    share many of the same facilities (most devices are commodity).

    For devices that differentiate themselves, the device vendor would
    ship proprietary interfaces and/or get involved in defining new
    interfaces in the process and/or ship a library that knows what
    a libhal device unique id is.

 2. Get support libraries to support the interfaces
    there may be real adoption issues etc. and practical problems in
    doing this, but it should be possible..

 3. Find a way that libhal load support libraries on-demand in a clever
    way since we cannot have a one giant libhal with all device
    support libraries. D-BUS activation maybe?

 4. Make sure that we don't wrap or carry information / functionality
    best belonging in other places.. In other words, we need to 
    be a thin abstraction layer in some sense.

And we also need to maintain these interfaces over time for ABI
stability but there are ways of dealing with this problem..

Currently my first mile-stone is to show that hot-plugged storage
devices work in a desktop environment and then look at integration
with device-support libraries for e.g. cameras..

You are very welcome to contribute to the spec or implementation with
your ideas.

Cheers,
David

[1] : http://pdx.freedesktop.org/~hal/