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:	Fri, 28 Jul 2006 01:24:27 +0200
From:	Vojtech Pavlik <vojtech@...e.cz>
To:	Shem Multinymous <multinymous@...il.com>
Cc:	"Brown, Len" <len.brown@...el.com>, Pavel Machek <pavel@...e.cz>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org, linux-acpi@...r.kernel.org
Subject: Re: Generic battery interface

On Thu, Jul 27, 2006 at 11:32:39PM +0300, Shem Multinymous wrote:

> >Also, critical battery alarms are important events.
> 
> Yes, but not time-sensitive.

They well can be. And it'd be pretty stupid to just throw away the
events the hardware offers to us and use polling from userspace, too.

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

You're joking, right? On quite a number of laptops, it takes quite a
while to read the battery, spent in BIOS through SMI, polling the I2C
bus while talking to the battery. The less often this is done, the
better.

> I'm yet to see any deployed userspace code
> trying to query battery status more than once per second.

The applets that were doing it (yes, up to 100 times per second)
corrected their ways pretty quickly, because some machines became
unusable with the applet enabled.

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

You could, trivially, mirror the behavior of current applets: Not report
the changes to the battery status more often than each N seconds, except
for critical events.

Said that, there haven't been many problems reported in the input layer
that I could attibute to bad default selection of fuzz.

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

May you be more specific here? I'm not aware of any problems in this
area. This may be my fault: What needs to be fixed there?

-- 
Vojtech Pavlik
Director SuSE Labs
-
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/