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

[Richard Hughes]

On Mon, 17 Jan 2005 13:28:12 -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.

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

>  - we merge properties saying execute the ACPI battery polling addon
>    if the linux.acpi.type (or whatever) says it's a battery
>  - the ACPI battery polling addon sets appropriate battery.* properties

Point. 

I think maybe linux.acpi.procfs_path might be better than
linux.procfs_path - in which case shouldn't we have a device object:

linux.power_system = acpi | pmu 

so that the addon code knows what to query (my way of thinking) or the
addon launch code knows which addon to launch (your way)

> 
> One thing to keep in mind is that the addon should be minimal; do as
> much as you can in hald without requiring the addon (basically, only
> set the battery.charge_level.current). 

Is there a technical reason for this? Would some people not be running the
addon code?

I sortof imagined the addon would populate all the data - it saves
coding the same thing in two different places. The plan for battery was to 
have hald set the device as present, and for the battery addon to update
all the computed values.

> 
> PMU implementations would do something similar.
> 
> How does that sound?

Sounds like we are getting somewhere :-)

Richard

-- 

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


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