david at fubar.dk
Fri Dec 17 11:52:17 PST 2004
On Fri, 2004-12-17 at 18:40 +1300, leon breedt wrote:
> i'm not sure i understand exactly what the 0.5.x add-on feature is
> intended to be used for yet.
Basically, the goal is to have an standard and extensible way of adding
features to extract information from specific hardware. Such as polling
for ink level, wireless mouse battery status or whatever.
> i currently have a scenario where i've written a stripped down volume
> manager (the host this is being used on has no desktop software
> running), and this volume manager just mounts the volume, scans it for
> specific metadata files, if present, does some stuff, and then
> unmounts it again once its done. this is really useful for updates to
> disconnected boxes via CD/memory stick, for example, and doesn't
> require much user education :)
> would i be able to accomplish these same tasks with an add-on? or are
> add-ons not intended for this purpose at all?
I guess, on a headless box, what you want to do is just write a callout
that does this . You may also write a separate daemon that just
listens to signals from hald; much like gnome-volume-manager, just
without the UI bits.
 : today this is as simple as dropping a file in /etc/hal/device.d -
in the 0.5.x series that will be changed such that you can specify the
callout in a .fdi file.
> secondly, what is the intended protocol for communication between hald
> and the add-on? will it be executed for every event, receiving
> arguments pertaining to that event, or will hald keep it around in
> memory (ala squid helpers) and communicate over stdin/stdout?
What I have in mind involves just executing a binary with the UDI and
device properties in the environment. When that device object goes away,
hald will send a SIGTERM to that process. The process may communicate
with hald using the D-BUS interface (or libhal which are the C bindings
for this interface).
hal mailing list
hal at lists.freedesktop.org
More information about the Hal