Message-ID: <20070416015705.GA29933@zarina>
Date:	Mon, 16 Apr 2007 05:57:05 +0400
From:	Anton Vorontsov <cbou@...l.ru>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Ondrej Zajicek <santiago@...reenet.org>,
	linux-kernel@...r.kernel.org, kernel-discuss@...dhelds.org,
	dwmw2@...radead.org
Subject: Re: [PATCH 3/7] [RFC] Battery monitoring class

On Sun, Apr 15, 2007 at 09:57:22PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 16 Apr 2007, Anton Vorontsov wrote:
> > 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.
> 
> What about SBS-style battery firmware, which can report *both* ?  This
> includes just about all ThinkPads in the last five years, so we are talking
> about a damn big lot of machines...

Sure, no problem. I'm taking away my words "if hardware can report
only average values, it's just okay to use usual attributes", and replacing
them by "if hardware can report only average values, it should use _AVG
attributes".

So, this scheme should work now:

1. If userspace (nice GUI app) seeing _avg values, it will use these.
2. If userspace seeing no _avg values, it is using its own statistics
   mechanism, i.e. collecting information from momentary attributes.
3. If userspace seeing both, it can decide, most probably it will decide
   to use hardware averaged values, i.e. _avg.

> I'd really appreciate if there is a standard way to communicate both.  And
> it is probably a good idea to define what should be averaged, and what
> should be instantaneous when that matters, that way userspace actually has a
> chance at not doing something braindamaged.
> 
> Actually, IMHO, every attribute and alarm from SBS should be somehow
> losslessly translatable to standard class attributes from day one, unless it
> is something that makes no sense at all (and there is precious little of
> that in the latest version of SBS, thankfully...).
> 
> > 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.
> 
> No, that won't help much.  IMO, we want the sanest set of standard
> attributes we can get, and weird as it might be, average reporting are
> common properties of battery control firmware on laptops (maybe because of
> SBS, but still...).

Why that won't help? Is there something else besides momentary and
hardware-averaged values?

> We don't have to get it perfect at the first try, but I really think we are
> getting a bit too far from "as good as we can make it" at the first attempt
> if we don't take the SBS into account properly, given the ammount of
> circuits and firmware out there that are shaped along the SBS guidelines.

I guess the only question for you is whether we would use, "attr" as momentary
and "attr_avg" as averaged by hardware value, or will use "attr" as averaged
values, and something alike "attr_now" for momentary? And you voting for
"attr" being averaged and "attr_now" momentary.

Actually, I don't see much difference, except default assumption of "attr"
being averaged/momentary.

Though, if it's real issue for you or SBS conformity, I can surely rename
attrs.

> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> 

And again, much thanks for your comments! They're really helpful.

-- 
Anton Vorontsov
email: cbou@...l.ru
backup email: ya-cbou@...dex.ru
irc://irc.freenode.org/bd2
-
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