Hello, Mark Lord wrote: > So have we. sysfs is a total nightmare to extract information from > under program / script control. The idea presented in this thread, > is to have it cross-index the contents with a method that actually > makes it easy to access in many common scenarios, without requiring > huge gobs of code in user space. Or in kernel space. > > And it's not just a few 10s of lines of code currently, > but rather about 80-100 lines just to find the correct device subdir, > and *then* a few more 10s of lines of code to retrieve the value. > > In a bulletproof fashion, that is. Sure it can be slightly smaller > if niceties such as error checking/handling are omitted. > > There's no guarantee that udev is present, and even if it were present, > there's no guarantee that the names in /dev/ will match /sysfs/ pathnames, > since udev is very configurable to do otherwise. > > So lookups are by dev_t, which sysfs has no simple or even easy way > of accomplishing. O(n) at a minimum. > > If we make it easier to access, then more programs will use it > rather than us having to expand our tricky binary ioctl interfaces. > > Isn't that part of the idea of sysfs -- to limit the need for new ioctls ? The questions are... 1. Are we gonna push sysfs as the primary interface and not provide an alternative interface (ioctl here) which can provide equivalent information? There are people running their systems w/o sysfs but I think we're getting closer to this everyday. 2. Is udev an essential part of all systems? I'm not sure about this one. Lots of small machines run w/o udev and I think udev is a bit too high level to depend on for every system. If both #1 and #2 are true, I agree with Mark that we need an easy to map from device number to matching sysfs nodes. Tools which are used early during boot and emergency sessions need this mapping and many of them are minimal C program w/o much dependency for a good reason. Requiring each of them to implement their own way to map device node to sysfs node is too awkward. Probably something like /sys/class/block/MAJ:MIN or /sys/class/devnums/bMAJ:MIN? -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
