On Sat, Jul 29, 2006 at 03:51:45PM +0300, Shem Multinymous wrote: > >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. If that app opens /dev/something by default, which is usually the case, there is only one step. > >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... I believe it was originally intended as a cleaner replacement for procfs - to allow the kernel export information about itself in a clean, safe, and consistent way. It wasn't intended for data delivery. I don't know whether the current state of things is good or bad. > Given the current usage pattern of sysfs, is it still a bad idea for > it to carry device inodes? That remains an open question. -- Vojtech Pavlik Director SuSE Labs - 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
