Ideas for spec for PMU/ACPI, Was: Patch to hal-spec : 1/6-pmu-acpi

[David Zeuthen]

On Mon, 2005-01-17 at 19:27 +0000, Richard Hughes wrote:
> Point taken. Some of the battery.* properties looked quite scary (e.g.
> battery.rechargeable.time_to_charge), hence why I assumed they would need
> some maths to work out.
> 
> I guess hal shouldn't really work *anything* out, but instead leave that
> to the application... in which case you're dead right.
> 

Yeah, I think you are right here.

> >> > Addons will be able to access all properties, yeah. The way I'd like 
> >> > this to be is
> >> > 
> >> >  - hald discovers ACPI functionality and adds suitable device objects
> >> >    with linux.acpi.* properties. Also adds properties system.* and
> >> >    battery.* as appropriate 
> >> 
> >> How *exactly* would this happen? I'm looking at adding checks to
> >> compute_coldplug_list() but I'm not sure how to handle the device types,
> >> hard-coding seems a bit brutal.
> >> 
> > 
> > You need to "hardcode" it; basically, test if /proc/acpi exists and then
> > start adding device objects as appropriate.
> 
> Sure, good for me. Is compute_coldplug_list() the best place to put the
> /proc/acpi/* checks?
> 

I would just call it from osspec_probe() to begin with; you can just add
the device object to the GDL (rather than the TDL) since you don't need
to
run callouts to begin with. So, the code should be pretty simply I
guess,
just

 d = hal_device_new(); 
 <set properties on d>; 
 hal_device_store_add (hald_get_gdl(), d)

for every device object you want to add.

(we can add callouts later since this will change on HEAD with my yet-
to-
be-committed patch). 

> > 
> > I'd like as many properties set before the device is announced as being
> > added, that's why. Addon code is only to be used for polling stuff. And
> > the only reason I want code in addons is because hald shouldn't be
> > polling.
> > since it may block the entire daemon. Come to think of it, we probably
> > could do the polling for ACPI inside hald since it's just reading a file
> > from /proc.
> 
> I'm good either way. I must admit I'm partial to the addon approach to
> keep everything modular, but maybe it could live neater inside hald proper.
> 

Cool.

> Richard
> 
> p.s. I'm sure I'm writing emails simultaneous to you, hence why we are
> having parallel conversions..!
> 

Heh, yeah, indeed.

Cheers,
David


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