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

Richard Hughes ee21rh at surrey.ac.uk
Thu Jan 13 14:39:30 PST 2005


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.

Richard

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


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



More information about the Hal mailing list