Re: Device Namespaces

[James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>]

On Mon, 2013-09-30 at 09:11 -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 30, 2013 at 08:37:19AM -0700, James Bottomley wrote:
> > On Thu, 2013-09-26 at 10:07 -0700, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 26, 2013 at 08:01:31PM +0300, Janne Karhunen wrote:
> > > > That being said, our wish would be to support any combination of
> > > > OS's and frankly, I'd be slightly annoyed to tell the customer that
> > > > they can't do two Androids or we magically run out of bits.
> > > 
> > > If you want to support "any" combination of operating systems, then use
> > > a hypervisor, that's what they are there for :)
> > 
> > No that's not quite the right way to think about it: The correct
> > statement is only use a hypervisor if you need different kernels.  With
> > Windows, it happens to be true that you need a different kernel for each
> > different OS version.  However; with Linux, thanks to strong ABI
> > backwards compatibility, you mostly don't.  The way OpenVZ works today
> > is that it installs a modified kernel which can then bring up every
> > Linux OS in a separate container.  Our use case is the hosters that give
> > you root login to a virtual private server and allow you to upgrade it
> > on your own.  The reason for using a container rather than a hypervisor
> > is the old density and elasticity one:  3x the density (i.e. 1/3 the
> > overhead cost to the hoster) and the boot only needs to start at init,
> > not bring up of virtual hardware and booting a second kernel.
> 
> I understand that some people really like the idea of using OpenVZ for
> various things like this, but to claim that because of it we need to
> hack up the driver core in the kernel into unimaginable pieces is not
> necessarily something that I'll agree with.

I don't believe I claimed that.  In fact, from 3.9 we can already bring
up an OpenVZ containerised system running different versions of Linux
that you can give someone root access to with no kernel modifications
whatsoever.  The user space solution currently works for us because
we're handing out server VPSs, so the device configuration is fixed as
we init the container.  However, we do have use cases for dynamic
instead of static device configurations, which is why we're
participating in the debate.

> But all of this is just words, I have yet to see any patches for any of
> this, so I'll just wait until that happens before worrying about it...

Well, that's because we're still debating what the best approach is.  If
you want a historical parallel: the comments you make above (hack up
the ... kernel into unimaginable pieces) is an almost exact mirror of
the comments that were made rejecting the in-kernel Checkpoint/Restore
patches at the 2010 Kernel Summit ... yet we have it fully functional
today in a form that proved acceptable.

James