lkml.org 
[lkml]   [2006]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Generic battery interface
    On Sat, Jul 29, 2006 at 02:32:02PM +0300, Shem Multinymous wrote:
    > On 7/29/06, Vojtech Pavlik <vojtech@suse.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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-29 14:09    [W:3.752 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site