Using devices

[Kiran Kumar Immidi]

On Wed, 2004-01-21 at 00:59, David Zeuthen wrote:
> 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)

Yes.. It could be more general.. any device.. located anywhere.
Something like gnome-vfs does for file systems - HAL could do for
devices.

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

  This is exactly what I had in mind. I got this idea from the
netfilter/iptables architecture, where they have things called
targets/matches (each of which is a shared library) which are
dynamically loaded using dlopen()/request_module() in userspace and
kernel space. This architecture would enable device support to be
"plugged" into HAL. Then the HAL device interface would provide
something more complete (in the sense operations that we expect of the
device would be available).


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

Regards,
Kiran Kumar Immidi