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:	Thu, 27 Jul 2006 12:50:39 -0400 (EDT)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Shem Multinymous <multinymous@...il.com>
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 Thu, 27 Jul 2006, Shem Multinymous wrote:

> On 7/27/06, Brown, Len <len.brown@...el.com> wrote:
> > Path names and file names in sysfs are an API, so it is important
> > to choose them wisely.  The string "acpi" should not appear in
> > any path-name or file-name in sysfs that is intended to be generic,
> > as it would make no sense on a non-ACPI system.
> >
> > Neither the ACPI /proc/acpi/battery API or
> > the tp_smapi /sys/devices/platform/smapi API qualify as generic.
> > It it a historical artifact that /proc/acpi exists, I'd delete it
> > immediately if that wouldn't instantly break every distro on earth.
> 
> Yes. But it looks like we'll have a hard time finding this common
> interface, due to overlaps and omissions between battery drivers.

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.

Of course, userspace can figure out which features are available by 
checking which files exist in the sysfs directory.

	-Daniel
*This .sig left intentionally blank*
-
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/