linux-kernel - Re: Generic battery interface

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:	Fri, 28 Jul 2006 01:56:03 +0300
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Pavel Machek" <pavel@...e.cz>
Cc:	"Brown, Len" <len.brown@...el.com>,
	"Matthew Garrett" <mjg59@...f.ucam.org>, vojtech@...e.cz,
	"kernel list" <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org, linux-acpi@...r.kernel.org,
	"Greg KH" <greg@...ah.com>
Subject: Re: Generic battery interface

On 7/28/06, Pavel Machek <pavel@...e.cz> wrote:

> Event interface suits PC world where BIOS already does the
> polling...

The BIOS does polling only for its internal tasks. It doesn't generate
events when readouts change unless something important happened. So if
you want readouts you need to poll the SMBIOS or hardware, like on the
Zaurus.

> + perhaps it would not need explicit maintainer, just assign names
>         carefully

We also need to decide on clear convention about units. Are they in
the output and/or filename? Filename is best, I think, since it's
impossible to miss and works nicely for input attributes too.

> - does not suit PC-style batteries which trigger events when data
>         change (can be fixed by /sys/XXX/anything-new, which gives one
>         byte when something changes)

Changed since last poll? That doesn't work with multiple clients.
Changed for the last X seconds? That requires everybody to poll that
frequenty, and risks missing events due to system load.

Wild thought: how about adding a generic "event source" mechanism into
sysfs, at the same level as attributes? Maybe even make them textual,
in keeping with sysfs philosophy:

while read TYPE PARAM  < /sys/class/battery/BAT0/criticl_events; do
  echo "battery 0 generated ctitical event $TYPE with parameters $PARAM"
done

The simpler solution is to convert events into state (e.g.,
critical=0/1) and present them as normal attributes which userspace
can poll, as Greg KH suggested (did I get that right?). I'm not sure
it's always easy, e.g., does ACPI genereate an explicit
no-longer-critical event?

> - you are not getting atomic snapshot of battery state. For example
>         you could read battery status okay, voltage 9.5V; while real
>         states were (okay, 10.5V), (critical, 9.5V) and update
>         happened between you reading status and voltage. (Is it
>         problem?)

I can't think of a realistic scenario where it's a problem. The latest
readout is always the best one to look at.

> - hard to handle obscure features
>         (do_not_charge_battery_for_X_minutes)

So where does that go in the /dev scheme?

  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/