[lkml]   [2007]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/7] [RFC] Battery monitoring class

On Mon, Apr 16, 2007 at 12:08:54AM +0200, Ondrej Zajicek wrote:
> On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> > Here is battery monitor class. According to first copyright string, we're
> > maintaining it since 2003. I've took few days and cleaned it up to be
> > more suitable for mainline inclusion.
> Just some ideas:
> - what about using exponents in values?
> For example file "voltage" could contain "123 -3" to represent 123 mV.
> Exponents could be hardcoded in drivers according to device's range
> (so there is no complication in it), but interface is usable in great
> range of values. And it is pretty easy to use from userspace.

No, sorry. Common units is main goal of that class. If you're saying
"energy" you always know that it's uWh. It's better for both userspace
(don't bother to parse anything from kernel) and kernel itself.

No need to invent new kernel<->userspace protocols, no need to do
useless string manipulations in kernel itself.

> - interface should allow to present values which are some monotonic
> functions of common physical properties. For example when we know
> where are some raw data from sensor, but we don't know where are
> calibration tables to be able to compute value in some standard unit
> (as V for voltage) - in this case it is better to show raw data
> (or raw data after some transformation which makes them monotonic)
> and specify that this is raw data than show nothing.
> - it would be nice to know whether presented value is from some
> measurement or it is (inaccurate) estimation.

Current battery class assumes values are not averaged. I.e. momentary
values. In general, it's userspace' job to collect statistics. Though,
if hardware can report only average values, it's just okay to use
usual attributes.

Also, if you your battery can collect and report its approximated values
in additional to momentary values, you're free to add _AVG attributes
to standard ones and use them.

> --
> Elen sila lumenn' omentielvo
> Ondrej 'SanTiago' Zajicek (email:, jabber:
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3,
> "To err is human -- to blame it on a computer is even more so."

Thanks for comments!

Anton Vorontsov
backup email:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-04-16 00:57    [W:0.140 / U:0.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site