On 7/29/06, Vojtech Pavlik <[email protected]> wrote:
> 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.
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.
> 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.
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...
Given the current usage pattern of sysfs, is it still a bad idea for
it to carry device inodes?
Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
