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

[David Zeuthen]

On Mon, 2005-01-17 at 18:54 +0000, Richard Hughes wrote:
> 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.
> 

I'm not sure we should have any "logic"; we just read values from a
file and populate device properties, no?

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

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

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.

> > 
> > PMU implementations would do something similar.
> > 
> > How does that sound?
> 
> Sounds like we are getting somewhere :-)
> 

Indeed :-)

David


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