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:	Sat, 29 Jul 2006 15:42:25 +0200
From:	Vojtech Pavlik <vojtech@...e.cz>
To:	Shem Multinymous <multinymous@...il.com>
Cc:	"Brown, Len" <len.brown@...el.com>, Pavel Machek <pavel@...e.cz>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org, linux-acpi@...r.kernel.org,
	Henrique de Moraes Holschuh <hmh@...ian.org>
Subject: Re: Generic battery interface

On Sat, Jul 29, 2006 at 03:51:45PM +0300, Shem Multinymous wrote:

> >IMO the right way here would be to have a nice GUI for configuring udev
> >included with the distro, that'd let you browse the sysfs tree and
> >point'n'click to create the rule you need.
> 
> That's still an extra level of indirection. You have to use the nice
> GUI to create a new /dev/something, and then point your at at dev
> /dev/something. And you have to be root to do that, whereas some sysfs
> stuff is world-readable.

If that app opens /dev/something by default, which is usually the case,
there is only one step.

> >The reason behind this was to force people NOT use sysfs directly when
> >interfacing to the OS. ;)
> >
> >Because sysfs wasn't intended to be an API you can rely on, one that's
> >fixed in stone and cannot be changed for compatibility reasons. I
> >believe it failed in that respect.
> 
> Is sysfs supposed to be a private" API that only "special services
> services" look at? It has definitely failed in this respect -- It's
> just too convenient and attractive. I'm not sure that's a bad thing...

I believe it was originally intended as a cleaner replacement for procfs
- to allow the kernel export information about itself in a clean, safe,
and consistent way. It wasn't intended for data delivery. 

I don't know whether the current state of things is good or bad.

> Given the current usage pattern of sysfs, is it still a bad idea for
> it to carry device inodes?
 
That remains an open question.

-- 
Vojtech Pavlik
Director SuSE Labs
-
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/