From: Greg KH <gregkh@suse.de>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tytso@mit.edu, sandeen@redhat.com, adilger.kernel@dilger.ca,
hch@infradead.org, axboe@kernel.dk
Subject: Re: [RFC PATCH 0/2 v1] Ioctl for reading block queue information
Date: Thu, 9 Dec 2010 11:20:50 -0800 [thread overview]
Message-ID: <20101209192050.GA26457@suse.de> (raw)
In-Reply-To: <1291908337-18805-1-git-send-email-lczerner@redhat.com>
On Thu, Dec 09, 2010 at 04:25:35PM +0100, Lukas Czerner wrote:
> Hi all,
>
> 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.
> This patch set adds new block ioctl BLKGETQUEUEINFO, which is designed to
> retrieve particular block queue attributes. I have tried to not to
> create completely new interface, but since we already have those
> information within block queue sysfs kobjects, rather retrieve it from
> there.
Ick, no, please just use the sysfs files, don't create a new ioctl, they
are horrid.
>
> So it binds enum blkq_info_type in include/linux/fs.h with
> default_attrs[] definition within block/blk-sysfs.c for ordering
> purposes, so the userspace has reliable way to address specific
> block queue attribute.
>
> In order to avoid string parsing (given that 99% of block queue sysfs
> attributes are of unsigned long type) I have introduced new sysfs_ops
> member *get which may be used to pass pointer to any type of data (unsigned
> long in this case). Then this get method is used to withdraw information
> through kobject->ktype->sysfs_ops.
>
> Although there are some downsides of this approach I would like to discuss:
>
> 1. In current state BLKGETQUEUEINFO and the whole infrastructure allow to
> retrieve only numeric values (no text), this means we are no able to
> retrieve schedule information.
>
> 2. Adding new *get member into sysfs_ops. I see this as the most painful
> downside, however, when we have more subsystems adding ioctls like this,
> they can easily use this method, the same way I am using it now.
Nope, don't do this, just use sysfs how it is supposed to be used, from
userspace.
sorry,
greg k-h
next prev parent reply other threads:[~2010-12-09 19:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 15:25 [RFC PATCH 0/2 v1] Ioctl for reading block queue information Lukas Czerner
2010-12-09 15:25 ` [PATCH 1/2] blk-sysfs: Clean-up attribute definitions Lukas Czerner
2010-12-09 15:25 ` [PATCH 2/2] Add BLKGETQUEUEINFO for reading block queue attributes Lukas Czerner
2010-12-10 18:39 ` Arnd Bergmann
2010-12-09 19:20 ` Greg KH [this message]
2010-12-09 19:49 ` [RFC PATCH 0/2 v1] Ioctl for reading block queue information Andreas Dilger
2010-12-09 19:54 ` Greg KH
2010-12-10 14:07 ` Lukas Czerner
2010-12-10 17:34 ` Greg KH
2010-12-10 17:59 ` Lukas Czerner
2010-12-10 18:25 ` Kay Sievers
2010-12-10 18:38 ` Lukas Czerner
2010-12-10 17:51 ` Kay Sievers
2010-12-10 17:54 ` Lukas Czerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101209192050.GA26457@suse.de \
--to=gregkh@suse.de \
--cc=adilger.kernel@dilger.ca \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=lczerner@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.