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

[Richard Hughes]

On Mon, 17 Jan 2005 14:16:13 -0500, David Zeuthen wrote:
>> > Don't you think it's easier, from a maintainability point of view, to
>> > have
>> > separate code for ACPI and PMU?
>> 
>> No, (IMHO) because they would be 99% the same. All the battery logic would
>> be the same in both cases, just the source of information might be
>> /proc/battery:charge for pmu and /proc/acpi/BAT0/state:charge for acpi.
>> 
> 
> I'm not sure we should have any "logic"; we just read values from a
> file and populate device properties, no?

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.

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

Richard

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

-- 

http://www.hughsie.com/PUBLIC-KEY


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