On Mon, Apr 16, 2007 at 03:32:54AM +0100, ian wrote:
> On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote:
> >
> > 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...).
>
> We need to think very carefully here.
>
> charge, current, capacity, etc. are properties all batteries have, and
> the current values can all be sampled instantaneously.
>
> funky values processed by 'black box' firmware are not universal
> properties of all batteries.
>
> IOW, battery class should be for 'simple' battery types only.
>
> perhaps rename it to simple battery class to make it distinct?
>
> Userspace is the place to put the complications, in any case, and I see
> nothing wrong with having both a simple battery class AND other
> proprietary battery class an SBS battery class. (or a
> toshiba_proprietary_bios battery class or whatever).
>
> Perhaps we need a 'libbattery.so' so that userspace can have a nice
> consistent interface?
Why? With current battery class we can do whatever everyone needs. No
need for wrappers.
Adding new properties is cheap and easy. Simple batteries using only
"simple" properties/attributes, and complicated batteries using
complicated attributes.
Because of your original design, simple batteries are stay simple, and
no noticing that there is some "complicated" attributes exists at all.
That's indeed great characteristic of that *universal* battery class.
For example, ds2760 is not really "simple" monitoring chip. ADC battery
is (it's in -hh tree so far). So, ds2760 is somewhere in between SBS
design, and dumb ADC batteries.
So, my another purposal, which I very like now:
Let's do self-documented properties. current_now, current_avg, e.t.c.
No more just "current", lets remove any ambiguousness!
--
Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
