From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [RFC PATCH 0/2 v1] Ioctl for reading block queue information Date: Thu, 9 Dec 2010 11:54:01 -0800 Message-ID: <20101209195401.GA27819@suse.de> References: <1291908337-18805-1-git-send-email-lczerner@redhat.com> <20101209192050.GA26457@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Lukas Czerner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, sandeen@redhat.com, hch@infradead.org, axboe@kernel.dk To: Andreas Dilger Return-path: Received: from cantor.suse.de ([195.135.220.2]:39258 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755814Ab0LITzG (ORCPT ); Thu, 9 Dec 2010 14:55:06 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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