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 14:32:02 +0300
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Vojtech Pavlik" <vojtech@...e.cz>
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 7/29/06, Vojtech Pavlik <vojtech@...e.cz> wrote:

> I think we're hitting a fundamental problem with sysfs/hotplug/udev
> here. It was created to get fixed, non-changing names of devices in
> /dev, so that they'd be easy to enter into configuration files.
>
> Yet applications today want automatic discovery of devices and don't
> want to rely on udev getting the names right.
>
> We should make our minds up, and decide whether we want the 'devices are
> in /dev and applications just need to open the filename' or the 'an
> application will find the device itself' approach.

I think what people want from device choice is a reasonable default
plus a convenient way to override things. The former is handled nicely
by distributions' udev rules, while the latter is best done by
providing fixed paths. As an end-user, if I know my favorite joystick
is on a specific USB port (hence a specific syfs directory), then I
want to tell neverball "use that one" without setting up nasty udev
rules or playing major:minor matchup. Yes, that's bypassing the Proper
Udevian Way of Doing Things, but it's so much easier and Unix-like
that we really should make it possible (though not by default!).

Security issues aside (for a moment):
Is there any reason not to provide real device inodes on sysfs,
instead of just a textual /sys/foo/dev? And then, maybe udev should
symlink to those device files under /sys instead of creating its own?
This would tie the two systems together rather elegantly.

> This reminds me very much of the Joerg Schilling discussion (flamewar)
> of enumerating CD-burners. Most people on the kernel mailing list just
> wanted to enter the name of the device node on the cdrecord command
> line. Yet Joerg insisted that the application should do the discovery.

I think there's a lot more to *that* flamewar - such as unwavering
belief in generic scsi...

> > If you rattle your ThinkPad this badly, latency in Neverball is going
> > to be the least of your problems. :-)
>
> HDAPS, as explained above, doesn't have huge latency impact. The reason
> to have high update rates for input devices (mice nowadays run at 100 Hz
> refresh usually, gaming mice up to 1 kHz), is to not introduce
> additional delay to the user->computer->user closed control loop.
>
> The less delay, the better stability of the control loop and the better
> results in the game. The limiting factor is usually 3D rendering, but a
> 10 Hz joystick will still kill the experience by inducing a much larger
> delay.

Yes, I understand. I just pointed out that in the specific case of
system accelerometer readouts, either the readouts change very slowly
or your laptop is being rattled into an early death.

> Sort of a 'reverse select'.

Exactly.

  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/