Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932262AbWBPPhf (ORCPT ); Thu, 16 Feb 2006 10:37:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932294AbWBPPhf (ORCPT ); Thu, 16 Feb 2006 10:37:35 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:28328 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S932262AbWBPPhe (ORCPT ); Thu, 16 Feb 2006 10:37:34 -0500 Date: Thu, 16 Feb 2006 09:37:29 -0600 From: "Serge E. Hallyn" To: "Eric W. Biederman" , "Serge E. Hallyn" , Kirill Korotaev , linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org, 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: <20060216153729.GB22358@sergelap.austin.ibm.com> References: <20060215145942.GA9274@sergelap.austin.ibm.com> <20060216143030.GA27585@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060216143030.GA27585@MAIL.13thfloor.at> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2039 Lines: 64 Quoting Herbert Poetzl (herbert@13thfloor.at): > > - Should a process have some sort of global (on the machine identifier)? > > this is mandatory, as it is required to kill any process > from the host (admin) context, without entering the pid > space (which would lead to all kind of security issues) Just to be clear: you think there should be cases where pspace x can kill processes in pspace y, but can't enter it? I'm not convinced that grounded in reasonable assumptions... > > - Should the pids in a pid space be visible from the outside? > > yes, while not strictly required, folks really like to > view the overall system state. this can be done with the > help of special tools, but again it should be done > without entering each guest pid space ... > ... > > - Should we be able to monitor a pid space from the outside? > > yes, definitely, but it could happen via some special > interfaces, i.e. no need to make it compatible What sort of interfaces do you envision for these two? If we can lay them out well enough, maybe the result will satisfy the openvz folks? For instance, perhaps we just use a proc interface, where in the current pspace, if we've created a new pspace which in our pspace is known as process 567, then we might see /proc /proc/567 /proc/567/pspace /proc/567/pspace/1 -> link to /proc/567 /proc/567/pspace/2 Now we also might be able to interact with the pspace by doing something like echo -9 > /proc/567/pspace/2/kill and of course do things like cd /proc/567/pspace/1/root > > - After migration what identifiers should the tasks have? > > doesn't matter, as long as they are unique, so > ppid1/ppid2/ppid3/pid would work ... And where are we talking about? Is this an identifier for userspace tools? Or just in kernelspace? -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/