Re: [RFC PATCH 0/2 v1] Ioctl for reading block queue information

[Greg KH <gregkh@suse.de>]

On Thu, Dec 09, 2010 at 12:49:32PM -0700, Andreas Dilger wrote:
> On 2010-12-09, at 12:20, Greg KH wrote:
> > On Thu, Dec 09, 2010 at 04:25:35PM +0100, Lukas Czerner wrote:
> >> For a long time it has been pretty painful to retrieve informations from
> >> /sys/block/*/queue for particular block device. Not only it is painful
> >> to retrieve informations within C tool, parsing strings, etc, but one
> >> have to run into problem even finding the proper path in sysfs.
> > 
> > What's wrong with using libudev?  That should give you all of this
> > information easily using a .c program without any need to change the
> > kernel at all.
> > 
> > Ick, no, please just use the sysfs files, don't create a new ioctl, they
> > are horrid.
> 
> Can you please show a real example of how using libudev is less horrid
> than just calling "ioctl(fd, BLKGETQUEUEINFO, &val)"?

It doesn't need permissions to open that fd in the first place, and in
maintaining the ioctl from within the kernel code, it's a _world_ easier
to handle over time.

I'm not saying that your .c code is somehow "easier" than just using an
ioctl, I'm saying that it is "future proof and saner" to use libudev
than to try to parse sysfs files yourself.

> How is trying to map a block device name from /etc/mtab (via
> getmntent()) into a possibly wildly different block device name in
> /sys (e.g. /dev/vgroot/lvhome vs. /dev/dm-0 vs.
> /dev/mapper/vgroot-lvhome => /sys/block/dm-0), then parsing text
> output considered a "good API"?

Again, use libudev, it handles that mapping for you and you don't have
to parse text output.

good luck,

greg k-h