David Zeuthen david at
Mon Dec 13 17:50:10 PST 2004

On Tue, 2004-12-14 at 00:50 +0000, Sergey Udaltsov wrote:
> Hello
> Just some general thoughs regarding addons and related properties
> (just some food for thought, very far from beeing considered as an
> attempt to specify something).
> I think, there should be some different policies for the addons
> invocation and termination. Possible evident variants:
> - Launch the instance of addon for every attached device - and kill
> (sending probably SIGUSR1?) on the device unplug.

Basically, yeah. 

> - Launch the instance of the addon for the first device within some
> group - and kill once the last member of the group is unplugged (is it
> useful in any way?)

I'm not sure this is useful - for interesting devices that makes sense
for addons, running an extra copy isn't a big deal. There won't be too
many of them either.

> - Launch single, per-system, instance of the addon once first device
> is plugged (requiring this addon) - and killing when the last is gone

Probably not useful either; an addon may implement it's one "Am I
running" checks.

> - Start on hald startup, stop on hald shutdown.

If this is the case one can just merge properties on the root computer
hal device object.

> Probably, there can be other variants, combinations. So what I see
> here is three properties:
> - (string) - the path to the binary executable
> - (string) - one of the predefined policyt names
> - (string) - optional, the name of the group
> The policies should be supported by the hald and libhal - so minimal
> coding on the addon side is required. I think manually coding these
> things in each addon is not a WTG.

I'm not sure this covers the cases where a device object has several
capabilities (e.g. functional elements). Instead it should probably look

for polling on wireless mice battery and e.g.

for polling on something else. A more realistic example is this

for a wireless USB harddisk :-). So, if I'm a open source project (or an
OEM) I can just do
poll-for-specific-harddisk from a .fdi file.

The process managing life cycles would scan the*
properties and do the right thing for each of them on device add/remove.


hal mailing list
hal at

More information about the Hal mailing list