[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BB2F083.1050803@kernel.org>
Date: Wed, 31 Mar 2010 15:49:39 +0900
From: Tejun Heo <tj@...nel.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Greg Kroah-Hartman <gregkh@...e.de>,
Kay Sievers <kay.sievers@...y.org>,
linux-kernel@...r.kernel.org,
Cornelia Huck <cornelia.huck@...ibm.com>,
linux-fsdevel@...r.kernel.org,
Eric Dumazet <eric.dumazet@...il.com>,
Benjamin LaHaise <bcrl@...et.ca>,
Serge Hallyn <serue@...ibm.com>, netdev@...r.kernel.org,
Benjamin Thery <benjamin.thery@...l.net>
Subject: Re: [PATCH 3/6] sysfs: Implement sysfs tagged directory support.
Hello, Eric.
On 03/31/2010 03:31 AM, Eric W. Biederman wrote:
> What this patch does is to add an additional tag field to the
> sysfs dirent structure. For directories that should show different
> contents depending on the context such as /sys/class/net/, and
> /sys/devices/virtual/net/ this tag field is used to specify the
> context in which those directories should be visible. Effectively
> this is the same as creating multiple distinct directories with
> the same name but internally to sysfs the result is nicer.
This has become a long running project. :-)
The way to implement partial visibility seems much cleaner now and I
don't have any objection. Thanks for cleaning up the whole sysfs and
implementing this properly. Unfortunately, I still feel quite
uncomfortable about how the scope of visibility is determined and how
deep knowledge about specific namespace implementation seeps down to
kobject / sysfs layer. It almost looks like a gross layering
violation.
Is it at all possible to implement it in properly layered manner?
ie. sysfs providing mechanisms for selective visibility, driver model
wraps it and exports it and namespace implements namespaces on top of
those mechanisms? I can see that there should be some interaction
between the driver model and namespaces but I can't see why that
information should be visible deep down in kobject and sysfs.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists