[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070416143425.GB5695@khazad-dum.debian.net>
Date: Mon, 16 Apr 2007 11:34:25 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Anton Vorontsov <cbou@...l.ru>
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
> > > 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?
It wouldn't help much to not have standard generic attributes for the
averaged measurements.
That said, yes, there are relative measurements (percent), and time
measurements (some battery firmware can tell you how much *time* it will
take to stop recharing, empty the battery, etc).
> 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.
I don't care either way, as long as it is *documented* what is averaged, and
what is instantaneous.
--
"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
-
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