[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41840b750610232004k46e4937emfcdff4f1aef0b30f@mail.gmail.com>
Date: Tue, 24 Oct 2006 05:04:17 +0200
From: "Shem Multinymous" <multinymous@...il.com>
To: "David Zeuthen" <davidz@...hat.com>
Cc: "Greg KH" <greg@...ah.com>,
"David Woodhouse" <dwmw2@...radead.org>,
linux-kernel@...r.kernel.org, olpc-dev@...top.org,
mjg59@...f.ucam.org, len.brown@...el.com, sfr@...b.auug.org.au,
benh@...nel.crashing.org
Subject: Re: Battery class driver.
On 10/24/06, David Zeuthen <davidz@...hat.com> wrote:
> b) if the kernel ensures that the 'timestamp' file is updated last,
> we get atomic updates
Atomic updates require either double-buffering the data (twice worse
than mere caching...) or locking away access during update (in which
case the order doesn't mater).
But yes, lack of atomicity in sysfs is a big issue. We don't seem to
have any ABI convention for providing atomic snapshots of those
dozen-small-atribute directories.
> Notably user space can see _when_ the values from the hardware was
> retrieved the last time
> This is a good thing, but is orthogonal to the how-do-we-poll issue.
> So.. how all this relates to hwmon I'm not sure.. looking briefly at
> Documentation/hwmon/sysfs-interface no such thing seems to be available,
Yes, hwmon ignores merrily ignores this issue, as do all other
data-through-sysfs drivers I've looked at. Except for the patched
hdaps driver in the tp_smapi package, which has a (very) rudimentary
solution via caching and a configurable in-kernel polling timer.
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