[ltp] RE: Generic battery interface

[Brown, Len]

> ... need a consistent interface to common functionality.

Agreed.

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.

Re: battery events

Vojtech suggested that we create a virtual battery interface,
just like the input layer has virtual input devices.
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.

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.

With a /dev/battery0, and IOCTLS to get information from it,
the question becomes redundancy between that file and sysfs
text files.

Re: sysfs or /dev

It is tempting to claim that sysfs is extensible, but note
that whenever you create a sysfs file, you are creating an API,
which is a decision of exactly the same magnitude as defining
an IOCTL -- in either case, user-space needs to react to it
to understand it -- just that you can do that from the shell
with sysfs.

-Len