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
>> 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
>> 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
> 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?