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