Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751320AbWBOWU5 (ORCPT ); Wed, 15 Feb 2006 17:20:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751322AbWBOWU4 (ORCPT ); Wed, 15 Feb 2006 17:20:56 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:39575 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1751320AbWBOWU4 (ORCPT ); Wed, 15 Feb 2006 17:20:56 -0500 To: "Serge E. Hallyn" Cc: Kirill Korotaev , linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org, Herbert Poetzl , Alan Cox , Dave Hansen , Arjan van de Ven , Suleiman Souhlal , Hubertus Franke , Cedric Le Goater , Kyle Moffett , Greg , Linus Torvalds , Andrew Morton , Greg KH , Rik van Riel , Alexey Kuznetsov , Andrey Savochkin , Kirill Korotaev , Andi Kleen , Benjamin Herrenschmidt , Jeff Garzik , Trond Myklebust , Jes Sorensen Subject: Re: (pspace,pid) vs true pid virtualization References: <20060215145942.GA9274@sergelap.austin.ibm.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 15 Feb 2006 15:12:13 -0700 In-Reply-To: <20060215145942.GA9274@sergelap.austin.ibm.com> (Serge E. Hallyn's message of "Wed, 15 Feb 2006 08:59:42 -0600") 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: 2588 Lines: 67 "Serge E. Hallyn" writes: > Hi, > > the lkml discussion on pid virtualization has been covering many of the > issues both relating directly to pid virtualization, and relating to > optimizations in the two specific implementations. > > However, if we're going to get anywhere, the first decision which we > need to make is whether to go with a (container,pid), (pspace,pid) or > equivalent pair like approach, or a virtualized pid approach. Linus had > previously said that he prefers the former. Since there has been much > discussion since then, I thought I'd try to recap the pros and cons of > each approach, with the hope that the head Penguins will chime in one > more time, after which we can hopefully focus our efforts. Does anyone see problems with implementing this as series of namespaces? If not we can move forward and start talking about pids, and the other namespaces. With respect to pids lets not get caught up in the implementation details. Let's first get clear on what the semantics should be. - Should the first pid in a pid space have pid 1? - Should pid == 1 ignore signals, it doesn't have a handler for? - Should any children of pid 1 be allowed to live when pid == 1 is killed? - Should a process have some sort of global (on the machine identifier)? - Should the pids in a pid space be visible from the outside? - Should the parent of pid 1 be able to wait for it for it's children? - Is a completely disjoin pid space acceptable to anyone? - What should the parent of pid == 1 see? - Should a process not in the default pid space be able to create another pid space? - Should we be able to monitor a pid space from the outside? - Should we be able to have processes enter a pid space? - Do we need to be able to be able to ptrace/kill individual processes in a pid space, from the outside, and why? - After migration what identifiers should the tasks have? If we can answer these kinds of questions we can likely focus in on what the implementation should look like. So far I have not seen a question that could not be implemented with a (pspace, pid)/pid or a vpid/pid implementation. I think it is safe to say that from the inside things should look to processes just as they do now. Which answers a lot of those questions. But it still leaves a lot open. 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/