[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41840b750704121023h65edaae5td942e4093bb8b0a3@mail.gmail.com>
Date: Thu, 12 Apr 2007 13:23:27 -0400
From: "Shem Multinymous" <multinymous@...il.com>
To: "Anton Vorontsov" <cbou@...l.ru>
Cc: linux-kernel@...r.kernel.org, kernel-discuss@...dhelds.org,
dwmw2@...radead.org
Subject: Re: [PATCH 3/7] [RFC] Battery monitoring class
Hi Anton,
On 4/12/07, Anton Vorontsov <cbou@...l.ru> wrote:
> On Thu, Apr 12, 2007 at 11:00:07AM -0400, Shem Multinymous wrote:
> > I suggest adding "remaining operating time" and "remaining charging
> > time". You can try deducing these from the above attributes, but in
> > practice this gives very inaccurate predictions. On laptops (e.g.,
> > ThinkPad) the BIOS or EC often provides much better estimates, using a
> > more accurate physical model.
>
> Yes, sure. Feel free to add these attributes to the "standard" ones,
> along with your drivers. See (1).
That's a sound way to go around i. We just need to be careful about
naming conventions. For example, "*_charge" rather than "*_capacity,
so that we can later add "*_energy" analogously.
But specifically about {operating,charge} time remaining readouts, it
seems important to have them there from the beginning and have all
drivers implement them. Otherwise, userspace will just go ahead and
implement its own crude computation, so by the time when new
attributes and drivers are introduced, userspace will be full of bad
code. I've seen this happening with the tp_smapi ThinkPad driver -- I
introduced those attributes at a recent version, and then needed to
encourage userspace utility authors to dump their extrapolation
calcultions and use the attribute instead.
The rest of the missing attributes are not as imporant in this
respect, because userspace can't try to estimate them.
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