Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751648Ab0DEIRq (ORCPT ); Mon, 5 Apr 2010 04:17:46 -0400 Received: from mail-pv0-f174.google.com ([74.125.83.174]:36147 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751145Ab0DEIRj (ORCPT ); Mon, 5 Apr 2010 04:17:39 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ck6NsTwMOjk4fh0tcuDTJsTDpXfSvhYY5Zi+x0oAeCFb3tyb0ajxaNtch6ZR4e9Ok3 VjHI7ScWO1RyPkCou8AVhZNBo8NWmGcO1I5TBHDFbb7LSUTlbMVDGrBluKkKVkH6y13F XWNPpI7QCB+jIbL3ui2/8Q3mEf6QVrD3MLXmU= Message-ID: <4BB99C9C.4070308@gmail.com> Date: Mon, 05 Apr 2010 17:17:32 +0900 From: Tejun Heo User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Eric W. Biederman" CC: Greg Kroah-Hartman , Kay Sievers , linux-kernel@vger.kernel.org, Cornelia Huck , linux-fsdevel@vger.kernel.org, Eric Dumazet , Benjamin LaHaise , Serge Hallyn , netdev@vger.kernel.org, Benjamin Thery Subject: Re: [PATCH 3/6] sysfs: Implement sysfs tagged directory support. References: <1269973889-25260-3-git-send-email-ebiederm@xmission.com> <4BB2F083.1050803@kernel.org> <4BB30520.2030100@kernel.org> <4BB30644.9090809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3296 Lines: 102 Hello, Eric. On 03/31/2010 06:39 PM, Eric W. Biederman wrote: > Let me try a happy median between overwhelming and too little > information by giving you some experts, and a bit of overview. > > (Ugh after have writing this I certainly will agree that we > have some many layers in the device model that they become > obfuscating abstractions). Yeah, exactly, and this patchset is pushing it further with no documentation and indirections to high heavens. As someone who doesn't have much experience with namespaces, I can't make much sense of this patchset and it obfuscates the whole kobject thing more and that's a bad direction to be heading toward. > Looking through my code there are 3 types of callbacks. > - Callbacks to the namespace type of a children. > .child_ns_type Can you please also explain the relationships among kobjects, ns_types and NSes? > - Callbacks to find the namespace of a kobject. > .namespace > - Callbacks on the a namespace type to find the namespace > of a particular context. > .current_ns > .initial_ns (not used in my patchset) > .netlink_ns (not used in my patchset) > > In a world of weird explicitness I expect .child_ns_type and > .namespace could be made to go away by pushing through explicit > ns_type, and namespace parameters everywhere. But that seems > like an awful lot of unnecessary code churn and bloat with > the only real advantage being that we have an abstraction > stored explicit at each layer. * How much churn would it be? I would be willing to trade quite a bit if the following can go away. The sheer amount of indirection there scares me a lot. struct kobj_type { ... const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj); ... }; * Is it necessary to teach kobject layer the concept of namespaces? Wouldn't it be possible to let kobject and sysfs deal with tags and make namespaces use them? > static int kobj_bcast_filter(struct sock *dest_sk, struct sk_buff *skb, void *data) > { > struct kobject *kobj = data; > const struct kobj_ns_type_operations *ops; > > ops = kobj_ns_ops(kobj); > if (ops) { > const void *sock_ns, *ns; > ns = kobj->ktype->namespace(kobj); > sock_ns = ops->netlink_ns(dsk); > return sock_ns != ns; > } > > return 0; > } > > initial_ns is used to figure out what the initial/default > namespace is for a class of namespaces. We only report > with /sbin/hotplug events in the initial network namespace. > At least for now. > > static int kobj_usermode_filter(struct kobject *kobj) > { > const struct kobj_ns_type_operations *ops; > > ops = kobj_ns_ops(kobj); > if (ops) { > const void *init_ns, *ns; > ns = kobj->ktype->namespace(kobj); > init_ns = ops->initial_ns(); > return ns != init_ns; > } > > return 0; > } I can understand you would need two different ways of establishing the accessor depending on the mode of access (file IO or netlink) but can initial_ns ever be dynamic? Can't it just be void *inital_ns instead of a callback? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/