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: <20060729103707.26737.qmail@web36908.mail.mud.yahoo.com>
Date:	Sat, 29 Jul 2006 11:37:07 +0100 (BST)
From:	Mark Underwood <basicmark@...oo.com>
To:	Shem Multinymous <multinymous@...il.com>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>
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


--- Shem Multinymous <multinymous@...il.com> wrote:

> On 7/29/06, Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> > On Sat, 29 Jul 2006 01:10:40 +0300, Shem Multinymous said:
> > > On 7/28/06, Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> > > > Is there a reliable (or hack-worthy) way for the kernel to determine how
> > > > often the values are re-posted by the hardware?
> > >
> > > That's hardware-specific. Some drivers can know, others may just
> > > assume 1sec or 0.1sec or whatever.
> >
> > That smells suspiciously like "We need an API for the hardware-specific
> > bits f code to pass the generic bits a value for this..." (and the
> > hardware-specific part can either ask the battery, or return a
> > hard-coded "10 seconds" that somebody measured, or whatever)....
> 
> I don't think "update frequency" is a good abstraction. The hardware's
> update may not be variable and irrregular (e.g., event-based), and
> there's there's an issue of phase sync to avoid unnecessary latency.
> 
> The lazy polling approach I described in my last post to Vojtech
> ("block until there's  a new readout or N milliseconds have passed,
> whichever is later") looks like a more general, accurate and efficient
> interface.
> 

This sounds like a good idea. You could do a similar thing using sysfs by
providing a entry in sysfs which tells userland when the next update is going
to happen, the userland app can then decide to use this as it's next poll time
or not.

Mark

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



		
___________________________________________________________ 
Yahoo! Photos  NEW, now offering a quality print service from just 7p a photo http://uk.photos.yahoo.com
-
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/