Date:	Sat, 29 Jul 2006 14:04:11 +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 02:32:02PM +0300, Shem Multinymous wrote:
> 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!).

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.

> 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.

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.

> >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...

Sure. It was just one of the points raised there.

> >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.

You want the frequent readouts even for slow changes of the direction of
gravity there, that's what I wanted to say.

> >Sort of a 'reverse select'.
> 
> Exactly.

-- 
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/

Powered by blists - more mailing lists