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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric W. Biederman wrote [note: quoting sections out of order]:
Sam Vilain <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux