Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030406AbWBPSpJ (ORCPT ); Thu, 16 Feb 2006 13:45:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030419AbWBPSpI (ORCPT ); Thu, 16 Feb 2006 13:45:08 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:30153 "EHLO e6.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1030406AbWBPSpG (ORCPT ); Thu, 16 Feb 2006 13:45:06 -0500 Date: Thu, 16 Feb 2006 12:44:07 -0600 From: "Serge E. Hallyn" To: "Eric W. Biederman" Cc: "Serge E. Hallyn" , 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 Message-ID: <20060216184407.GC11974@sergelap.austin.ibm.com> References: <20060215145942.GA9274@sergelap.austin.ibm.com> <20060216142928.GA22358@sergelap.austin.ibm.com> <20060216175326.GA11974@sergelap.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2208 Lines: 56 Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" writes: > >> What happens when you migrate pspace 3 into a different pspace > >> on a different machine? > > > > Nothing special. "Migrate" was just a checkpoint (from pspace 1) > > and a resume (from pspace N on some machine). So now pspace N on > > the new machine has created a new pspace - which happens to be > > immediately populated with the contents of the old pspace 3 - and > > see the pid of the init process of this new pspace. > > > >> Is there a sane implementation for this? > > > > IMO, definately yes. > > > > But I haven't tried it, so my opinion is just that. > > If you are just talking the pid of the init process the problem seems > tractable. > > Where I see real problems with migration is and nested pid spaces > is when you expose all of your pids to your parent, and perhaps > there was some miscommunication on this point. > > To try and give an example. > > pspace 1 pspace 2 pspace 3 pspace 4 > pid 234 -> pid 1 > pid 235 -> pid 2 -> pid 1 > pid 236 -> pid 3 -> pid 2 -> pid 1 > > Hopefully this clearly shows what I was trying to avoid, by > only allow pid 1 of any pspace to be visible in the parent. Yes, I saw it more like: > pspace 1 pspace 2 pspace 3 pspace 4 > pid 234 -> pid 1 > pid 2 -> pid 1 > pid 2 -> pid 1 > pid 3 Now Dave and I were just talking about actually using the init process in a pspace to do administration from outside. For instance, the userspace code, in /sbin/pspaceinit, which runs as (pspace 2, pid 1), could open a pipe with it's parent (pspace1, pid 234). pid 234 can then ask the init process to do things like list processes, kill a process, and maybe even recursively talk to the init process in pspace 3. -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/