From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
rwheeler@redhat.com, snitzer@redhat.com, neilb@suse.de,
James.Bottomley@hansenpartnership.com, dgilbert@interlog.com,
jens.axboe@oracle.com, matthew@wil.cx, linux-ide@vger.kernel.org,
linux-scsi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2 of 9] block: Export I/O topology for block devices and partitions
Date: Fri, 24 Apr 2009 11:00:52 -0400 [thread overview]
Message-ID: <yq1ws9a85az.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <49F1B68D.3010304@garzik.org> (Jeff Garzik's message of "Fri, 24 Apr 2009 08:54:37 -0400")
>>>>> "Jeff" == Jeff Garzik <jeff@garzik.org> writes:
Jeff> Why do we need all this syscall overhead just to read individual
Jeff> data items?
Jeff> Isn't it dumb to require 30 userland syscalls simply to input a
Jeff> 10-member data structure?
Jeff> netlink looks more and more attractive for anything non-trivial.
I think these three knobs are very trivial :)
I agree that traversing sysfs can be sucky. But for the mkfs-es of the
world I expect most of this to be handled by libdisk.
I also I really wanted something that could be easily scripted for
installers to poke at.
If these values were in any kind of hot path I'd be inclined to agree
with the need for a different interface. But realistically these are
only ever going to be accessed when creating a filesystem, partition or
MD/DM device.
So I opted to keep things simple. Doesn't mean we can't add another
interface if there's a real need...
--
Martin K. Petersen Oracle Linux Engineering
prev parent reply other threads:[~2009-04-24 15:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <patchbomb.1240551141@sermon.lab.mkp.net>
[not found] ` <72f4e15760670febdb40.1240551143@sermon.lab.mkp.net>
[not found] ` <ac3eb2510904240514y660973abj7621864e11e514f2@mail.gmail.com>
2009-04-24 12:54 ` [PATCH 2 of 9] block: Export I/O topology for block devices and partitions Jeff Garzik
2009-04-24 14:37 ` Carl Henrik Lunde
2009-04-24 14:47 ` Matthew Wilcox
2009-04-24 15:16 ` Martin K. Petersen
2009-04-24 15:00 ` Martin K. Petersen [this message]
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=yq1ws9a85az.fsf@sermon.lab.mkp.net \
--to=martin.petersen@oracle.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dgilbert@interlog.com \
--cc=jeff@garzik.org \
--cc=jens.axboe@oracle.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=neilb@suse.de \
--cc=rwheeler@redhat.com \
--cc=snitzer@redhat.com \
/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