Re: Generic battery interface

From: Shem Multinymous
Date: Thu Jul 27 2006 - 12:21:57 EST

On 7/27/06, Brown, Len <len.brown@xxxxxxxxx> wrote:
Path names and file names in sysfs are an API, so it is important
to choose them wisely. The string "acpi" should not appear in
any path-name or file-name in sysfs that is intended to be generic,
as it would make no sense on a non-ACPI system.

Neither the ACPI /proc/acpi/battery API or
the tp_smapi /sys/devices/platform/smapi API qualify as generic.
It it a historical artifact that /proc/acpi exists, I'd delete it
immediately if that wouldn't instantly break every distro on earth.

Yes. But it looks like we'll have a hard time finding this common
interface, due to overlaps and omissions between battery drivers.

So I've proposed /sys/class/battery/{acpi,apm,thinkpad}/BAT?/* as a comrpromise:
A userspace app that only needs a generic voltage readout will try
(all of) /sys/class/battery/*/BAT0/voltage. This is your generic

A specialized app can be more specific and access

And a complex system monitor like GKrellM will let you configure a
list of paths, e.g., /sys/class/battery/acpi/BAT0 +

The only drawback I see is the inelegant userspace code for
enumerating /sys/class/battery/* in languages like C. I suppose this
could be wrapped by a trivial userspace library.

Vojtech suggested that we create a virtual battery interface,
just like the input layer has virtual input devices.
In either case, user-space would look for a well known set
of device file names, such as /dev/battery0, /dev/battery1
or some such, do a select on the file and get events that way.

Isn't this an overkill? Battery status changes very slowly, so it
seems perfectly adequate to have the usual userspace daemons poll the
kernel every few seconds. No need for extra kernal event mechanisms,
device file allocation, IOCTLs...

Drivers such as above could conjur up devices, and user-space
could also create what look like batteries, say through a
utility that knows how to talk to a UPS.

Excellent idea, but it's orthogonal to the API issue. You might as
well have /sys/class/battery/usespace-battery/UPS0.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at