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

[David Zeuthen]

On Thu, 2005-01-13 at 22:39 +0000, Richard Hughes wrote:
> On Thu, 13 Jan 2005 22:58:22 +0100, Sjoerd Simons wrote:
> >> >> Does PMU have any node-specific data? I don't know anything about PMU,
> >> >> other than PMUD is used to query it. 
> >> > 
> >> > Not really it's pretty simple.. Most stuff it knows is exported through
> >> > /proc, for some things you need to query/write to it though..
> >> > 
> > 
> > $ tree /proc/pmu
> >   /proc/pmu
> >   |-- battery_0
> >   |-- info
> >   |-- interrupts
> >   `-- options
> 
> Thanks Sjoerd, that's just what I wanted to see.
> 
> You're right about the pmu.* and acpi.* stuff, there's unneeded and
> duplicate information. We could just merge it into linux.* and provide a
> complete high level solution that doesn't care about whether a device is
> PMU or ACPI.
> 
> It would look something like this:
> 
> ...
> <row>
>   <entry><literal>linux.procfs_path</literal> (string)</entry>
>   <entry>example: /proc/acpi/button/power/PWRF, /proc/pmu/battery_0</entry>
>   <entry>No</entry>
>   <entry>
>     A fully-qualified path into the procfs filesystem for the 
>     physical device
>   </entry>
> </row>
> <row>
>   <entry><literal>linux.procfs_path.keyname</literal> (string)</entry>
>   <entry>example: "remaining capacity"</entry>
>   <entry>Yes, if linux.procfs_path is set</entry>
>   <entry>
>     The keyname that HAL can use to extract the data from the procfs file
>   </entry>
> </row>
> <row>
>   <entry><literal>linux.acpi_version</literal> (string)</entry>
>   <entry>example: 20041210</entry>
>   <entry>No</entry>
>   <entry>
>     The in-kernel driver version providing ACPI services
>   </entry>
> </row>
> <row>
>   <entry><literal>linux.pmu_device</literal> (string)</entry>
>   <entry>example: /dev/pmu</entry>
>   <entry>No</entry>
>   <entry>The udev assigned device file for PMU.</entry>
> </row>
> <row>
>   <entry><literal>linux.pmu_driver_version</literal> (string)</entry>
>   <entry>example: 2</entry>
>   <entry>No</entry>
>   <entry>PMU driver version</entry>
> </row>
> <row>
>   <entry><literal>linux.pmu_firmware_version</literal> (string)</entry>
>   <entry>example: 0c</entry>
>   <entry>No</entry>
>   <entry>PMU firmware version</entry>
> </row>
> ...
> 
> With this idea we could have a battery addon that polls the battery keys,
> which is common between ACPI and PMU. All the addons would be interface
> neutral. 
> 
> Comments as always please.
> 

I'm not really that concerned how the specific ACPI and PMU properties
look like; something that works and is documented is of course nice, but
at the end of the day, the interesting parts for consumers of this
is really the system.* properties; I mean, if applications start caring
whether something is PMU or ACPI we've failed to provide a suitable
abstraction.

Of course, we need to expose something about PMU and ACPI so the
different parts (detection code, addons and method call handlers)
of HAL itself can figure things out, but I suppose that as this 
is implemented we find out what it should look like? 

On the point of common battery polling code, I don't really think
this is useful as an addon should really be a small piece of code
reading stuff and populating the appropriate properties. I could
be wrong though.

Cheers,
David


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