Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750722AbWCYSkv (ORCPT ); Sat, 25 Mar 2006 13:40:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750830AbWCYSkv (ORCPT ); Sat, 25 Mar 2006 13:40:51 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:56806 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1750722AbWCYSku (ORCPT ); Sat, 25 Mar 2006 13:40:50 -0500 To: Herbert Poetzl Cc: Kirill Korotaev , Dave Hansen , Sam Vilain , linux-kernel@vger.kernel.org, OpenVZ developers list , "Serge E.Hallyn" , Andrew Morton Subject: Re: [RFC] [PATCH 0/7] Some basic vserver infrastructure References: <20060321061333.27638.63963.stgit@localhost.localdomain> <1142967011.10906.185.camel@localhost.localdomain> <44241224.9000200@sw.ru> <20060324210150.GA22308@MAIL.13thfloor.at> <20060324214029.GD22308@MAIL.13thfloor.at> From: ebiederm@xmission.com (Eric W. Biederman) Date: Sat, 25 Mar 2006 11:37:56 -0700 In-Reply-To: (Eric W. Biederman's message of "Fri, 24 Mar 2006 15:30:40 -0700") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1693 Lines: 40 ebiederm@xmission.com (Eric W. Biederman) writes: > Herbert Poetzl writes: > >> well, while /proc/mounts is a good example that it 'works' >> it isn't a good example for proper design, as the entire >> private namespaces lead to much obfuscation, and having >> the mounts per process, where they actually should be per >> namespace, and to hide the fact that there are different >> namespaces does not help either ... >> >> IMHO a much better design would be to have the namespace >> 'explicit' and link to that one, containig the mounts entry >> btw, this is something which should still be possible >> without breaking anything ... > > Actually I agree. That should work for everything except sysctl. > > The tricky bit is going to be sticky a pid on the namespace group. > But the patch should be quite simple. Actually the tricky bit is that there is no way to list resources that processes share, except for by looking at the processes. Changing that has performance implications and is at least slightly non-trivial. Given that the primary upside is better debugging I'm not a fan. I would much rather modify the interfaces to have double counts and work like the network devices. Where you get warnings when someone is still using the device after it has been made to go away. I appreciate the concern, and I share it. I just don't think that right now there is a good mechanism to get better visibility. Eric - 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/