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] [day] [month] [year] [list]

Message-ID: <41840b750607271307w76016f07wf6c5a4a04a62e008@mail.gmail.com>
Date:	Thu, 27 Jul 2006 23:07:53 +0300
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Daniel Barkalow" <barkalow@...ervon.org>
Cc:	"Brown, Len" <len.brown@...el.com>, "Pavel Machek" <pavel@...e.cz>,
	"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
Subject: Re: Generic battery interface

On 7/27/06, Daniel Barkalow <barkalow@...ervon.org> wrote:
> Maybe it would be best to have a virtual driver that knows about the union
> of the features, and makes whatever features are provided by the
> underlying driver available to userspace. That way, all of the drivers are
> implementing features out of a shared set, so you don't end up with
> thinkpad/force_discharge and something/discharge_battery. This is the
> principle behind, for example, the generic cdrom driver, which doesn't
> actually implement much but rather provides uniformity across devices
> handled by different drivers.
>
> I don't think this is a case where each driver provides very similar
> functionality, but with critical differences which can't be corrected for;
> it seems like features are clearly available or not.

It's a bit trickier than it first looks.

For example, take the "force discharge" and "inhibit charge" commands.
Do they take effect until further notice, or for a given time period?
Whichever variant you pick, the ThinkPad hardware can't do it: you can
only tell it to force discharging until further notice, and you can
only tell it to avoid charging for N minutes. Note that the variants
cannot emulate each other, because when the laptop is suspended the
embedded controller still ticks but the kernel can't use timers to
issue new commands.

Another examle: suppose one hardware interface provide average power
reading while another interface provides only voltage and average
current. The two are not equivalent: if you try to compute power as
voltage*current you'll get inaccurate results, because power is the
integral over (instantaneous current)*(instantaneous voltage) and the
latter fluctuates. So you'd want to somehow prioritize the first
interface over the second, at least when it comes to power readings.

These details are inconsequential for most applications, but some do
care. So an interface that forces a certain view and hides the rest
may not be a good idea.

  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/