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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
