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]

Date:	Thu, 27 Jul 2006 23:32:39 +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:
> Why not just specify the union of the different sets,
> and those that don't implement parts leave those parts out?

That's cool, as long as we still let drivers express minor differences
within the framework (see my last message to Daniel).

> >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.
>
> If we have to export all these totally different implementations
> via totally different paths, then we failed.

They're not totally different, they differ in a very specific way
which allows the difference to be ignored by applications that don't
care.

> sysfs is great for demos from a shell prompt,
> but isn't such a great programming interface, either
> from inside the kernel or from user-space.

<shrug>
I have my own list of sysfs gripes (e.g., how do you implement a
"query a register" interface?), but the powers that be decreed we're
supposed to use sysfs for this kind of stuff.

> Also, critical battery alarms are important events.

Yes, but not time-sensitive.

> Please do not add more polling to user-space, else DaveJ
> will be putting it up as a further example of "Why userspace sucks"
> at the next OLS:-)

Battery polling is already used extensively, and its overhead is
completely negligible. I'm yet to see any deployed userspace code
trying to query battery status more than once per second.

On the other hand, if you send an event whenever the voltage or
current change, you'll flood userspace with junk. So you'll need to
have a "fuzz" like in the input device code; but this may be
client-specific or hardware-specific. And you'll need to identify
devices in a useful way, a problem that's not yet solved even for
input devices... You see where it's going.

  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/