Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965152AbWBGQRU (ORCPT ); Tue, 7 Feb 2006 11:17:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965157AbWBGQRU (ORCPT ); Tue, 7 Feb 2006 11:17:20 -0500 Received: from mailhub.sw.ru ([195.214.233.200]:6021 "EHLO relay.sw.ru") by vger.kernel.org with ESMTP id S965152AbWBGQRU (ORCPT ); Tue, 7 Feb 2006 11:17:20 -0500 Message-ID: <43E8C84D.6020107@sw.ru> Date: Tue, 07 Feb 2006 19:18:21 +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: Sam Vilain , Rik van Riel , Kirill Korotaev , Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Hubertus Franke , clg@fr.ibm.com, haveblue@us.ibm.com, greg@kroah.com, alan@lxorguk.ukuu.org.uk, serue@us.ibm.com, arjan@infradead.org, kuznet@ms2.inr.ac.ru, saw@sawoct.com, devel@openvz.org, Dmitry Mishin , Andi Kleen Subject: Re: [PATCH 1/4] Virtualization/containers: introduction References: <43E7C65F.3050609@openvz.org> <43E83E8A.1040704@vilain.net> 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: 1768 Lines: 40 >>I can't think of any real use cases where you would specifically want A) >>without B). > You misrepresent my approach. [...] > Second I am not trying to just implement a form of virtualizing PIDs. > Heck I don't intend to virtualize anything. The kernel has already > virtualized everything I require. I want to implement multiple > instances of the current kernel global namespaces. All I want is > to be able to use the same name twice in user space and not have > a conflict. if you want not virtualize anything, what is this discussion about? :) can you provide an URL to your sources? you makes lot's of statements about that your network virtualization solution is better/more complete, so I'd like to see your solution in whole rather than only words. Probably this will help. > I disagree with a struct container simply because I do not see what > value it happens to bring to the table. I have yet to see a problem > that it solves that I have not solved yet. again, source would help to understand your solution and problem you solved and not solved yet. > In addition I depart from vserver and other implementations in another > regard. It is my impression a lot of their work has been done so > those projects are maintainable outside of the kernel, which makes > sense as that is where those code bases live. But I don't think that > gives the best solution for an in kernel implementation, which is > what we are implementing. These soltuions are in kernel implementations actually. 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/