Plans for hal 0.5.x

[David Zeuthen]

On Mon, 2004-12-13 at 11:17 +0100, Sjoerd Simons wrote:
> On Sun, Dec 12, 2004 at 11:05:50PM -0500, David Zeuthen wrote:
> >  3) Would be nice to map methods on arbitrary D-BUS interfaces for hal
> >     device objects to binaries. See my earlier mail today on encryption
> >     ideas. Can be used for a boatload of other stuff; e.g.
> >     SetLCDBrightness().
> > 
> >  4) Addons; make it easy to write and integrate e.g. the battery polling
> >     software that Sergey is working on; ideally what we today have for 
> >     polling a USB or CD-ROM drive would be such an addon.
> >
> >These are the new device types I'd like to add support for
>  
> > 4) ACPI/PMU: Should be a job of reading off files in /proc or using
> >    /dev/pmu. Sergey already did the spec of what the properties should
> >    look like; we should just use that. Also add support for laptop-
> >    specific interfaces through hal framework ideas 3) and 4) above.
> 
> Richard Hult and myself are talking about creating a dbus service to handle
> /dev/pmu and put info about it in hal. 

Nice.

> So for point 3 it would be nice to both
> map to binaries and to dbus methods.  
> 

Good point.

> But it probably won't be really an addon, because we want it to work too when
> there is no hal for whatever reason.
> 

Well, yeah, the ideal interface for handling addons should be something
simple like just managing the lifecycle of said addons. So, e.g. if I
got a hal device object with

 info.addon.<some-unique-addon-type> = /usr/sbin/pmu-hal-polling

then hald (some other component invoked by hald, probably) will ensure
that there is exactly one copy running for each hal device object with
the above line. The lifecycle is managed with fork/exec and kill; if the
invoked program exits prematurely (e.g. not being killed by hald), then
so be it.

So, it should probably be somewhat easy to integrate; if people don't
use hal they may just install an initscript you ship; if people do use
hal they don't install the initscript. The fact that your binary owns
another D-BUS service shouldn't be a problem AFAICT.

Cheers,
David



_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal