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.
-
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/