Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751657AbWBMJAv (ORCPT ); Mon, 13 Feb 2006 04:00:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751658AbWBMJAv (ORCPT ); Mon, 13 Feb 2006 04:00:51 -0500 Received: from mailhub.sw.ru ([195.214.233.200]:24924 "EHLO relay.sw.ru") by vger.kernel.org with ESMTP id S1751656AbWBMJAu (ORCPT ); Mon, 13 Feb 2006 04:00:50 -0500 Message-ID: <43F04B28.9090300@sw.ru> Date: Mon, 13 Feb 2006 12:02:32 +0300 From: Kirill Korotaev User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: "Eric W. Biederman" CC: linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org, Herbert Poetzl , "Serge E. Hallyn" , 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: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the process id namespace References: <43ECF803.8080404@sw.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2343 Lines: 55 >>Actually I can't say your patch is cleaner somehow. >>It is very big and most of the changes are trivial, which creates an illusion >>that it is straightforward and clean. > > > It is hard to make a comparison. Your patch posted to the mail list > was incomplete, and I could only find a giant patch for OpenVZ. this is wrong. it lacked only alpha get_xpid(). sure, we didn't do that dirty games with /proc you did, so maybe this is why you have such a feeling. > Beyond that if your patch introduced a type change for internal pids > and used that generate compile errors when someone did not use the > appropriate type, I would be a lot happier and the code would > be a lot more maintainable. I.e. It would not take an audit of > the kernel source to find the issues an allyesconfig build would find > them for you. it is not a problem at all and can be done. > I don't think my current implementation actually causes enough compile > errors, but I need think closely about it before I go much farther. > > Maintainable code is a delicate balancing act between things that > trip you up when you get it wrong, and not being so cumbersome you > get in the programmers way > The advantages I see with my approach. > - I have hierarchical pids so nesting is possible. Once again, our approach doesn't prohibit hierarchical pids. But in addition to yours it allows to select whether weak or strong isolation is required. > - The state after migration is not suboptimal. sorry? > - I cause compiler errors which makes maintenance easier. it is not a question to the approach itself, you see? so not an argument. > - Other kernel developers gut feel is that (container, pid) is the proper > representation. > I actually flip flop on the issue of if I want the internal representation > to be (container, pid) or a magic kpid that combines the into one integer. > I know I don't want the kpid to be user space visible though. > > So far you have not addressed the issues of maintaining code in the > kernel tree. Uhhh... I see that you have no real arguments. Nice. Kirill - 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/