Re: Generic battery interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/29/06, Vojtech Pavlik <vojtech@xxxxxxx> 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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux