From: Joel Becker <jlbec@evilplan.org>
To: James Bottomley <James.Bottomley@suse.de>
Cc: Bart Van Assche <bvanassche@acm.org>,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
Boaz Harrosh <bharrosh@panasas.com>
Subject: Re: Why using configfs as the only interface is wrong for a storage target
Date: Mon, 7 Feb 2011 10:45:02 -0800 [thread overview]
Message-ID: <20110207184501.GA13518@noexit> (raw)
In-Reply-To: <1297089709.3012.19.camel@mulgrave.site>
On Mon, Feb 07, 2011 at 08:41:49AM -0600, James Bottomley wrote:
> On Mon, 2011-02-07 at 03:53 -0800, Joel Becker wrote:
> > On Mon, Feb 07, 2011 at 12:41:18PM +0100, Bart Van Assche wrote:
> > > I'm still not convinced that using configfs in a storage target as the
> > > only interface between kernel space and user space is a good idea.
Two points here. First, a design principle of configfs is that
it cannot and should not be one-stop shop for all possible userspace
interaction. If there are things that fit better in sysfs, there is no
reason the target code can't export them via sysfs. So any contention
that we can't add other pieces of the puzzle in an attempt to shoehorn
everything into configfs is sub-optimal.
> I think the overall philosophical point here, and it's a good one
> because I've heard it from several sources, is that it's not possible to
> separate configuration from status completely. The classic example is
> where the kernel has to validate and adjust config information, but the
Nor should you try. You can certainly update the attributes of
objects created in configfs via the kernel, and you can certainly use
configfs with sysfs, ioctl, procfs, or netlink in the same subsystem.
Joel
--
Life's Little Instruction Book #226
"When someone hugs you, let them be the first to let go."
http://www.jlbec.org/
jlbec@evilplan.org
next prev parent reply other threads:[~2011-02-07 18:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-07 11:41 Why using configfs as the only interface is wrong for a storage target Bart Van Assche
2011-02-07 11:53 ` Joel Becker
2011-02-07 12:08 ` Bart Van Assche
2011-02-07 19:57 ` Nicholas A. Bellinger
2011-02-07 14:41 ` James Bottomley
2011-02-07 15:02 ` Emmanuel Florac
2011-02-07 20:09 ` Nicholas A. Bellinger
2011-02-07 21:38 ` Emmanuel Florac
2011-02-07 22:44 ` Joel Becker
2011-02-07 22:53 ` Joel Becker
2011-02-08 0:03 ` Nicholas A. Bellinger
2011-02-08 8:01 ` Emmanuel Florac
2011-02-07 15:10 ` Hannes Reinecke
2015-09-16 7:34 ` Sergiu
2011-02-07 18:45 ` Joel Becker [this message]
2011-02-07 20:01 ` Nicholas A. Bellinger
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=20110207184501.GA13518@noexit \
--to=jlbec@evilplan.org \
--cc=James.Bottomley@suse.de \
--cc=bharrosh@panasas.com \
--cc=bvanassche@acm.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.org \
/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).