linux-kernel - Re: Battery class driver.

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: <41840b750610240409g1dfd35e5vd9abcb2f6ea1ab1e@mail.gmail.com>
Date:	Tue, 24 Oct 2006 13:09:47 +0200
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Matthew Garrett" <mjg59@...f.ucam.org>
Cc:	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
	"David Zeuthen" <davidz@...hat.com>,
	"David Woodhouse" <dwmw2@...radead.org>,
	linux-kernel@...r.kernel.org, olpc-dev@...top.org, greg@...ah.com,
	len.brown@...el.com, sfr@...b.auug.org.au
Subject: Re: Battery class driver.

On 10/24/06, Matthew Garrett <mjg59@...f.ucam.org> wrote:

> The kernel backend or the userspace backend? We need to decide on
> terminology :) There's no good programmatic way of determining how long
> a query will take other than doing it and looking at the result. I guess
> we could do that at boot time.

This is up to the kernel driver. Most drivers have fairly accurate
knowledge about the hardware they read, in terms of both the cost of
reading and the rate of change that's worth tracking.

The important thing is to define an ABI convention that lets userspace
tell the driver when it wants the next refresh (via either David's
timestamp or my suggested ioctl). The driver can then make its
informed decision on how to reasonably fulfill the request.

  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/