[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41840b750607290435x379fe818t2df5c2d4ffd4125e@mail.gmail.com>
Date: Sat, 29 Jul 2006 14:35:16 +0300
From: "Shem Multinymous" <multinymous@...il.com>
To: "Mark Underwood" <basicmark@...oo.com>
Cc: "Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
"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 7/29/06, Mark Underwood <basicmark@...oo.com> wrote:
> > 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.
The driver may not know when the next update will happen, e.g., if its
data source is event-based. Moreover, the driver may be able to
*decide* when the next update will happen (i.e., when to query
poll-based hardware) if the clients say what they need in advance. The
"lazy poll" / "reverse select" handles both of these.
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/
Powered by blists - more mailing lists