Re: Generic battery interface

From: Daniel Barkalow
Date: Thu Jul 27 2006 - 12:47:25 EST

On Thu, 27 Jul 2006, Shem Multinymous wrote:

> 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.

Maybe it would be best to have a virtual driver that knows about the union
of the features, and makes whatever features are provided by the
underlying driver available to userspace. That way, all of the drivers are
implementing features out of a shared set, so you don't end up with
thinkpad/force_discharge and something/discharge_battery. This is the
principle behind, for example, the generic cdrom driver, which doesn't
actually implement much but rather provides uniformity across devices
handled by different drivers.

I don't think this is a case where each driver provides very similar
functionality, but with critical differences which can't be corrected for;
it seems like features are clearly available or not.

Of course, userspace can figure out which features are available by
checking which files exist in the sysfs directory.

*This .sig left intentionally blank*
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