Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753898Ab0LJRqj (ORCPT ); Fri, 10 Dec 2010 12:46:39 -0500 Received: from cantor.suse.de ([195.135.220.2]:52767 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752347Ab0LJRqi (ORCPT ); Fri, 10 Dec 2010 12:46:38 -0500 Date: Fri, 10 Dec 2010 09:34:06 -0800 From: Greg KH To: Lukas Czerner Cc: Andreas Dilger , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, tytso@mit.edu, sandeen@redhat.com, hch@infradead.org, axboe@kernel.dk Subject: Re: [RFC PATCH 0/2 v1] Ioctl for reading block queue information Message-ID: <20101210173406.GA11936@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 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3325 Lines: 92 On Fri, Dec 10, 2010 at 03:07:20PM +0100, Lukas Czerner wrote: > On Thu, 9 Dec 2010, 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. > > What's wrong with using libudev ? Well, fist of all I have never heard > about it:), one can argue this is kind of my fault, and second of all > the documentation is kind of non-existent (almost). > > But, despite this I did gave libudev a quick try and I must say, it > works, however it is not as simple as calling "ioctl(fd, > BLKGETQUEUEINFO, &val)" as Andreas pointed out. > > So, in my use-case, I have a path to the device provided by the user > (strictly speaking it may not be device but for example symbolic link > /dev/mapper/something) and I need to retrieve queue information like > discard_granularity, discard_alignment etc... usually stored in place > like /sys/block/sda/queue/*. > > With libudev I need to: > > 1. create the udev obejct: > > udev = udev_new(); > if (!udev) { > printf("Can't create udev\n"); > exit(1); > } > > 2. Check the path for the block device > > stat(name, &buf); > if (!S_ISBLK(buf.st_mode)) { > printf("Not a block device\n"); > exit(1); > } > > 3. Get udev device object > > dev = udev_device_new_from_devnum(udev, 'b', buf.st_rdev); > if (!dev) { > printf("Can not find the device\n"); > exit(1); > } > > 4. Construct path for sysfs attribute I need: > > snprintf(path, PATH_MAX, "%s/queue/%s", > udev_device_get_syspath(dev), > "discard_granularity"); Hm, what about just using the libudev functions for attributes instead? That should save you this step, and the next one. > 5. Open the sysfs file, get page-sized buffer and parse text :-/ (without > checks now): > > read(fd, buffer, pagesize); > sscanf(buffer, "%lu", &value); > printf("max_hw_sector_size: %lu\n",value); > > Which is opposed to BLKGETQUEUEINFO steps (define val, invoke ioctl, > check result) a bit longer. But I can definitely see you point, it is > feasible and since we have libudev we might want to use this in > userspace. The fact is I would really want to stand up and defend my > ioctl approach, but libudev just might provide what I need without > proceeding the just-another-ioctl-madness on kernel lists :). Please use libudev. What happens next week when we add a new sysfs attribute to block devices? Then your ioctl just broke and you have to create a new one. No, use sysfs for what it was made for, from userspace, don't add custom ioctls for this. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/