linux-kernel - Re: Generic battery interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <41840b750607270923j21074661v6254ba52ec67b67a@mail.gmail.com>
Date:	Thu, 27 Jul 2006 19:23:42 +0300
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Brown, Len" <len.brown@...el.com>
Cc:	"Pavel Machek" <pavel@...e.cz>,
	"Matthew Garrett" <mjg59@...f.ucam.org>, vojtech@...e.cz,
	"kernel list" <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org, linux-acpi@...r.kernel.org
Subject: Re: Generic battery interface

On 7/27/06, Brown, Len <len.brown@...el.com> 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
interface.

A specialized app can be more specific and access
/sys/class/battery/thinkpad/BAT0/force_discharge.

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

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.
[snip]
> 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.

  Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/