Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030631AbWBQOyN (ORCPT ); Fri, 17 Feb 2006 09:54:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030607AbWBQOyM (ORCPT ); Fri, 17 Feb 2006 09:54:12 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:1245 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S1030600AbWBQOyK (ORCPT ); Fri, 17 Feb 2006 09:54:10 -0500 Date: Fri, 17 Feb 2006 08:53:50 -0600 From: "Serge E. Hallyn" To: Hubertus Franke Cc: "Serge E. Hallyn" , "Eric W. Biederman" , Kirill Korotaev , linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org, Herbert Poetzl , Alan Cox , Dave Hansen , Arjan van de Ven , Suleiman Souhlal , 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 Message-ID: <20060217145350.GA26437@sergelap.austin.ibm.com> References: <20060215145942.GA9274@sergelap.austin.ibm.com> <20060216142928.GA22358@sergelap.austin.ibm.com> <43F5448A.6020501@watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43F5448A.6020501@watson.ibm.com> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1657 Lines: 46 Quoting Hubertus Franke (frankeh@watson.ibm.com): > >>- Should a process have some sort of global (on the machine identifier)? > > First establish whether that global ID has to be persistent ... > I don't see why ! In which case the TASK_REF is the perfect global ID. The task_refs were only intended to be used in the kernel, iiuc. ... > >>- Should we be able to have processes enter a pid space? > > > > > >IMO that is crucial. > > Existing ones .. now that is potentially difficult to do. Particular > if you want to enter a pidspace that has already been migrated. > Because ones assigned pid might already been taken in the target pspace. Well the answer changes depending on whether the question asks about pid spaces, or full containers. For full containers, you have problems with unsharing various pieces of namespace. But for the pidspace, a simple function with clone() semantics makes perfect sense. So your code does: child_pid = pidspace_clone(pspace_id); if (child_pid == 0) { /* we are inside pspace 'pspace_id' with a random pid which is unique in that pspace */ } else { /* the child_pid is known by some other pid in it's own pspace, but in our pspace it's known and hashed by 'child_pid'. child_pid and that other pid are likely different. */ } So long as we're just talking about the pidspaces, I don't see any unexpected side effects here. -serge - 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/