OLPC battery class

[David Woodhouse]

On Tue, 2007-06-19 at 15:55 +0100, Richard Hughes wrote:
> Hi,
> 
> I've been looking at adding OLPC battery support into HAL so it can be
> used with OHM and the power meter in sugar.

Cool, thanks.

> Putting it bluntly, the "generic battery class" is a bit of a misnomer,
> as it's very OLPC specific. 

Not at all. It handles at least two types of batteries already and it's
not particularly hard to make it handle APM and ACPI too -- these were
discussed when it was put together.

But it's actually already been revamped -- see Anton's git tree at
http://git.infradead.org/?p=users/cbou/battery2-2.6.git which will
shortly turn up in the olpc git tree, as soon as I've finished changing
it over to use the new EC communication protocol instead of direct
access. This already addresses some of your comments.

> * 'capacity' is probably the wrong word to use, in common use it means
> the battery capacity compared to when nit was new, to measure how the
> battery has degraded over time.
> 
> * 'status' and 'status_cap' violate the one-value-per file mentality
> of sysfs. This means we have to do string processing in HAL, rather
> than just read the value of a flag. status_cap shouldn't be used at at
> all - if the capability does not exist to report this, then do not
> export the attribute (so no file in sysfs). See below for an example.

I believe these are both changed in Anton's new code.

> * 'temp1' - why not temperature_ambient?
> * 'temp2' - why not temperature_internal?

Because then you have arbitrarily-named properties, rather than _known_
named properties. But I think Anton changed this anyway.

> * Why is the AC adapter exported as a battery of type ac? This is simply
> wrong, they are _completely_ different types of device.

No. They're _both_ power supplies. They can both have measurements of
voltage, current, temperature, etc. The external input is just like an
infinite battery.

-- 
dwmw2