Cc: Mark Lord <lkml@...>, H. Peter Anvin <hpa@...>, Jens Axboe <axboe@...>, Jeff Garzik <jgarzik@...>, Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>, Linux Kernel <linux-kernel@...>, IDE/ATA development list <linux-ide@...>, linux-scsi <linux-scsi@...>
On Wed, Mar 26, 2008 at 09:54:22AM +0900, Tejun Heo wrote:
I think you are using either the wrong programming language, or your
sysfs walking logic is quite convulted. Look at the udev and HAL code
if you want to steal some compact, working sysfs code :)
And again, is this a performance requiring operation?
Exactly, originally you suggested a new ioctl, 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.
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.
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.
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.
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? :)
thanks,
greg k-h
--
