Re: [PATCH 1/4] Virtualization/containers: introduction

[Sam Vilain <sam@vilain.net>]

Eric W. Biederman wrote [note: quoting sections out of order]:
> Sam Vilain <sam@vilain.net> writes:
>>Let's compare approaches of patchsets before the patchsets themselves.
>>It seems to be, should we:
>>   A) make a general form of virtualising PIDs, and hope this assists
>>      later virtualisation efforts (Eric's patch)
>>I can't think of any real use cases where you would specifically want A)
>>without B).
> You misrepresent my approach.  

ok, after reading more of your post, agreed.

 > What user interface to export is a debate worth having.

This is the bit that needs a long period of prototyping and experimental
use IMHO.  So in essence, we're agreeing on that point.

> First there is a huge commonality in the code bases between the
> different implementations and I have already gotten preliminary
> acceptance from the vserver developers, that my approach is sane.  The
> major difference is what user interface does the kernel export,
> and I posted my user interface.
 > 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.

Right, well, I think our approaches might have more in common than
I previously thought.

Indeed, it seems that at least one of the features of Linux-VServer I am
preparing for consideration for inclusion into Linus' tree are your work
:-).

> Beyond getting multiple instance of all of the kernel namespaces
> (which is the hard requirement for migration) my approach is to
> see what is needed for projects like vserver and vps and see how
> their needs can be met as well. 

ok, but the question is - doesn't this just constitute a refactoring 
once the stable virtualisation code is in?

I'm just a bit nervous about trying to 
refactor-approach-and-concepts-as-we-go.

But look, I'll take a closer look at your patches, and see if I can 
merge with you anyhow.  Thanks for the git repo!

Sam.