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]
Date:	Sun, 15 Apr 2007 21:57:22 -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

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...

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...).

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.

-- 
  "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