linux-kernel - Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

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: 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/