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

[Sjoerd Simons]

On Mon, Jan 17, 2005 at 06:54:23PM +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.
> 
> > 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)

Just wondering.. Do we want the code that reads/polls /sys and/or /proc 
entries as addons (well for entries that don't need special permissions) ? 

I don't think it's a problem to have one extra addon, but having a general
guideline to what should become an addon and what should stay in the main code
(or at least in a more general addon) would be nice :)

  Sjoerd
-- 
When some people discover the truth, they just can't understand why
everybody isn't eager to hear it.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal