Using devices

[David Zeuthen]

On Tue, 2004-01-20 at 07:33, Kiran Kumar Immidi wrote:
> Hi,
>   This is with reference to the "Using devices" section of the HAL
> specification. In the "Out-of-process D-BUS service", it says - "The
> volume manager could offer an operation for writing ISO images... A
> desktop file manager would use the HAL daemon to query for the HAL
> device object that is a CD recorder and pass the object reference to the
> D-BUS service offered by the volume manager."
> 

Right - these are only examples of course. In retrospect, managing
optical drives through a daemon might be a overkill. One would rather
use an inprocess library. I believe that for burning discs, the libburn
guys (also here on fd.o) were positive with regards to integrating with
HAL.

>   According to this, the object reference should be passed to the the
> D-BUS service offered by the volume manager. Would it not be more
> intutive if an interface to the device were available ( or a provision
> to make that available be available) for accessing the device. For
> instance if I get the object reference
> /org/freedesktop/Hal/devices/block_3_0 to a CDROM, it would be nice if
> it offered an "interface" to open/close/play, rather than having to pass
> the object reference to a third component (the D-BUS service like the
> volume manager). 
>
>   The approach described currently also means (perhaps) that there
> would a daemon sort of entity to handle requests for a particular set of
> devices, which would mean a lot of daemons if there a good number of
> devices. If there would be a defined central way to handle each of the
> devices, it would possibly rule out such proliferation of daemons.
> 

Yeah - for optical discs a shared library, lets call it
libhal_optical_disc, would be nicer. The C bindings might look like

  hal_optical_disc_eject(const char* udi);
  hal_optical_disc_close_tray(const char* udi);
  hal_optical_disc_play_audio(const char* udi, unsigned int track_nr);
  ...

of course with the provision that these can only be called when the user
has acquired the lock for the device (advisory locks of devices are soon
to be added in HAL). The bowels of the shared library would use libhal
to get block.device and so forth to actually perform operations
(ioctl(2) and friends) on the device.

So, going along the same lines I think that we should have one shared
library for one or more HAL capabilities, e.g. libhal_camera,
libhal_music_player. 

Of course, doing libhal_music_player, a library for transferring music
to your portable music player (think iPod, rio500 etc.) is harder. It
could involve

 a) going into the bowels of libipod, rio500 etc. and putting HAL
    support in them - it should be straightforward to get a patch into
    these as this can probably be configured at build-time. Handling
    devices based on usb-storage (my mp3 player is like) that probably
    needs to be written from scratch but it should be easy.

 b) defining an interface that is appropriate and represents all the
    devices covered. This might be harder as it requires intimate
    knowledge of the problem domain the capability represent.

 c) implement the library, e.g., map the incoming function calls to
    the appropriate library.

As HAL is available under a quite liberate license (dual: AFL + GPL),
one could even make such libraries respect plugins themselves. So if I'm
an OEM and wants to make my device work under Linux or another platform
on which HAL runs, I could just release a shared library and put in a
place so libhal_music_player would respect it. 
However, this is of course a choice to be made by whoever creates this
library, I personally don't have an opinion on this.

(music players are of course only an example)

Now, we talked about using devices through the network last week (think
SunRay style), it should be noted that having a single fd.o library
would allow us to solve at least the "using the device" part of the
problem, but I'm sure other problems exist that still needs to be
solved.

What would really rock my world would be getting libhal to load these
libraries, libhal_music_player, libhal_camera etc. on demand (using
dlopen() or whatever is available on the platform) as extensions -
someone suggested this a few months back 

https://listman.redhat.com/archives/xdg-list/2003-September/msg00085.html

Finally, I think having a single fd.o library per capability with an
API/ABI stability policy we can manage ourselves is a good long term
solution for "Making Hardware Just Work".

However.. I don't pretend this is the best solution to "Using Devices",
but I would like to know what others think of it.

>   It also refers to other ways of dealing with device-specific
> operations. Could any one enlighten me on these?
> 

This would be using shared libraries as described above.

Cheers,
David