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:	Sun, 30 Jul 2006 20:58:34 -0400
From:	Valdis.Kletnieks@...edu
To:	Shem Multinymous <multinymous@...il.com>
Cc:	Vojtech Pavlik <vojtech@...e.cz>, Pavel Machek <pavel@...e.cz>,
	"Brown, Len" <len.brown@...el.com>,
	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 Sun, 30 Jul 2006 14:48:07 +0300, Shem Multinymous said:
> On 7/30/06, Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> > If the program says '100ms' because it knows it will need to do a GUI update
> > then, and you block it for 5 seconds because that's when the next value
> > update happens, the user is stuck looking at their gkrellm or whatever not
> > doing anything at all for 4.9 seconds....

> Please read my detailed proposal, posted (and resivsed) later.

OK, if you meant this one (that hadn't shown up here before I hit 'send'):

On Sun, 30 Jul 2006 13:14:10 +0300, Shem Multinymous said:
> Actually my solution was "any update but no sooner than N msecs". So
> you might be getting a readout that's N-1 msecs old, which was
> meanwhile cached by the driver. If you care about that, you need to
> use interleave those polls with msleep()s; see my recent detailed
> post. You'll still doing at most one msleep() per fetched readout,
> regardless of how frequently the driver provides them.

That has slightly different semantics indeed, and avoids the issue I
was commenting about.  A gkrellm-ish program can query every 100ms and
get a cached value 49 times out of 50 for a value that's hardware-updated
every 5 seconds, and all will be well (of course, there's room for some
added optimization, but I suspect trying to add that will end up more
expensive than just re-reading the same cached value, unless the kernel has
a good way to pass back a good hint of when the next update will be...)

Content of type "application/pgp-signature" skipped