Hello, Greg. Greg KH wrote: >> 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. > > Exactly, originally you suggested a new ioctl, Well, I like Mark but am not really him. :-) > which would be trivial to > add, and trivial to switch any program that was currently using an ioctl > to get the disk size, to use it instead. That should be the simplest solution for the problem at hand. > Since when is the major:minor view of devices the "standard" one that > userspace uses? Last I looked, userspace uses symlinks and lots of > other ways of directly accessing block devices in /dev/, and does not > rely on major:minor. The fact that major:minor is the unique identifier of a device makes it a bit special compared to other names on filesystem. > And finally, I haven't seen a patch that implements this "shadow" tree, > it would be interesting to see if it could even be done. It's possible, all that's needed are symlinks. We do similar things all the time. >> 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. > > My tiny little phone runs udev, I don't see why anyone wouldn't run it > these days, except in very limited embedded applications with no dynamic > devices. But if you are in that situation, you aren't querying the size > of any random block device either :) > > And heck, this phone is a very limited embedded application, with razor > thin margins, if it can use udev, I'd be interested in hearing the > justifications for anyone who says it is too large for their systems to > use it. I agree udev is affordable for most cases but it's still a major step to require it for every system. I would hate to hear that hdparm or fdisk doesn't work unless udev is online. These are tools which are used to recover systems. >> 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? > > Why the preopcupation with major:minor? Just because you are able to > grab it from an open file handle? Heck, why not just an ioctl to get > the path within sysfs for the device currently open? :) Because major:minor is the key attribute to devices? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
