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 12:05:59 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	Shem Multinymous <multinymous@...il.com>
Cc:	Vojtech Pavlik <vojtech@...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,
	Henrique de Moraes Holschuh <hmh@...ian.org>,
	Mark Underwood <basicmark@...oo.com>
Subject: Re: Generic battery interface

Hi!

> >Here's one approach: use a syscall (e.g., ioctl) saying "block until
> >there's new data on this fd, or N milliseconds have passed, whichever
> >is *later*". This way each client declares the update rate it wants
> >and can change it on the fly. The driver sees all the requests and can
> >perform the minimum hardware quering -- for example, it won't query
> >the hardware at all if no client has submitted a request with
> >parameter N more than N milliseconds go. And there's no excessive work
> >or interrupts. Some (simple) kernel code infrastructure is needed to
> >help drivers manage the pending requests.
> 
> Here's a rough sketch for the userspace side of a continuous function
> sampling interface. It handles the blocking a bit better than the
> above proposal, in that it lets you easily handle multiple readouts.
> It's agnostic about /dev vs. /sys.

Looks good to me.

> I'm not getting into the kernel side for now; it's doable, and with
> proper infrastructure (e.g., at the sysfs level) can be elegant and
> efficient.

I guess that hwmon people would like this, anyway...

Are there any plans at merging tp_smapi, BTW? After fixing few minor
details (like removing " mV" from files)... it looks like it would fit
into hwmon infrastructure rather nicely.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/