[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5050E3F5.3080008@intel.com>
Date: Wed, 12 Sep 2012 19:35:18 +0000
From: "Love, Robert W" <robert.w.love@...el.com>
To: Chris Leech <leech@...ox.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"devel@...n-fcoe.org" <devel@...n-fcoe.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: [Open-FCoE] [RFC PATCH 0/5] Reorganize libfcoe control
interfaces
On 12-09-11 10:36 AM, Love, Robert W wrote:
> On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
>> On Mon, Sep 10, 2012 at 3:59 PM, Robert Love <robert.w.love@...el.com> wrote:
<snip>
> This feels a little awkward with all the special control files. Have
> you thought about something designed for creating kernel objects, like
> configfs? Similarly the separate start, enable, disable files vs.
> Let me do some more reading about configfs. I may not have given it
> enough thought.
I read though the configfs documentation and the fact that it's designed
for user driven object creation does fit with what I'm trying to do. I
have a couple concerns that I'm trying to sort through now-
1) This adds a new dependency for boot. I don't know if that is a
problem or not. Are there any examples of configfs being mounted in an
initrd?
2) Using configfs would likely mean that I'd be creating controller
instances and possibly FCF instances in configfs, since they're already
there in sysfs these objects would be duplicated. I'm not sure there's
harm in that, but it certainly feels disjointed and messy. I suppose we
could remove the /sys/bus/fcoe stuff in favor of configfs if it's the
right thing to do.
Thanks, //Rob--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists