From: Lukas Czerner <lczerner@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, sandeen@redhat.com,
adilger.kernel@dilger.ca, gregkh@suse.de, hch@infradead.org,
axboe@kernel.dk, lczerner@redhat.com
Subject: [RFC PATCH 0/2 v1] Ioctl for reading block queue information
Date: Thu, 9 Dec 2010 16:25:35 +0100 [thread overview]
Message-ID: <1291908337-18805-1-git-send-email-lczerner@redhat.com> (raw)
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.
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.
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.
3. One might say that this is basically promoting sysfs to API, but I would not
so strict about this. We can always change this to be independent on sysfs,
but I have choose this approach mainly because this way we are able to
maintain just one engine with two interfaces.
4. All this seems a little hackish :)
So, I would like to hear your comments on this, not just "this is entirely
stupid", but also "look, this may be the better way", because obviously we
can not be adding new ioctls for every piece of information (BLKDISCARDZEROES,
etc..) user-space needs.
Thanks!
-Lukas
---
[PATCH 1/2] blk-sysfs: Clean-up attribute definitions
[PATCH 2/2] Add BLKGETQUEUEINFO for reading block queue attributes
block/blk-sysfs.c | 370 +++++++++++++++++++------------------------------
block/ioctl.c | 32 +++++
include/linux/fs.h | 30 ++++
include/linux/sysfs.h | 1 +
4 files changed, 207 insertions(+), 226 deletions(-)
next reply other threads:[~2010-12-09 15:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 15:25 Lukas Czerner [this message]
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 ` [RFC PATCH 0/2 v1] Ioctl for reading block queue information Greg KH
2010-12-09 19:49 ` 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=1291908337-18805-1-git-send-email-lczerner@redhat.com \
--to=lczerner@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=axboe@kernel.dk \
--cc=gregkh@suse.de \
--cc=hch@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).