[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BDAF5B0.3080801@kernel.org>
Date: Fri, 30 Apr 2010 17:22:24 +0200
From: Tejun Heo <tj@...nel.org>
To: "Serge E. Hallyn" <serue@...ibm.com>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
Greg KH <gregkh@...e.de>, bcrl@...et.ca,
benjamin.thery@...l.net, cornelia.huck@...ibm.com,
eric.dumazet@...il.com, kay.sievers@...y.org,
netdev@...r.kernel.org
Subject: Re: patch sysfs-implement-sysfs-tagged-directory-support.patch added
to gregkh-2.6 tree
Hello,
On 04/30/2010 04:29 PM, Serge E. Hallyn wrote:
> Hmm, but looking back over the previous thread (Mar 31) I guess you
> mean more in-line comments around the callbacks, presumably things
> like class_dir_child_ns_type() and struct kobj_ns_type_operations
> members?
In-line. What they're, how they're supposed to be used, which calling
context is expected, what can be returned and so on.
> It sounds like what you'd really like is to have any explicit
> mention to namespaces pulled out of drivers/base (layering as you
> keep saying)? But will there be a use for this outside of
> namespaces? Does trying to anticipate that fall into the category
> of over-abstraction?
I wouldn't mind limited amount of layering exceptions as long as
they're clearly documented. What I'm primarily worried about is not
the possibility of other users but more the obfuscation of the whole
sysfs-kobject-driver model thing which is already overly abstracted
and obfuscated (at least it seems to me that way).
NS needs tagged support in the driver model which in itself is fine
and I also understand that from someone who's primarily working on NS,
adding a bit on top of the whole thing wouldn't seem like much of a
problem. To me it seems like worsening a problem which is already
pretty bad. I hope you could understand my POV too.
Thanks.
--
tejun
--
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