Current-Users archive

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

Re: Lightweight virtualization - the rump approach



On Mon May 17 2010 at 12:02:36 +0200, Jean-Yves Migeon wrote:
> I am probably missing something then; p2k being a translation layer, it is
> shared between the different rump_* parts. As such, I considered
> (wrongfully maybe?) that the interface/protocol communication is not
> expected to change with regards to rump_* components. Which means that
> having rump_somefs support is a matter of making its code run in userland,
> and talk with the kernel through p2k (which remains untouched in this
> case).

p2k uses syscalls/vnodeops to talk with the kernel file servers.  So both
p2k and the kernel code remain unchanged.

But you still need to *mount* the file system.  That's what the
rump_somefs utility is all about (and likewise mount_somefs).  Have a look
at the code and the fourth argument to mount(2) and you'll understand.

> > I don't care about domU differences that much (in my use case), it's the
> > dom0 which is the showstopper.  Frankly, I'd love to be able to run my
> > anita testing with xen instead of qemu, since unaccelerated qemu tends
> > to be quite slow (and my laptop doesn't support VT-x anyway).
> 
> IIUC:
> 1 - you want GENERIC to be bootable directly as a dom0, just to be able to
> launch Xen PV guests
> 2 - perform anita test on a GENERIC kernel launched within a domU
> 
> Correct?

I'm more interesting in "1", purely based on it being convenient (for me,
at least).  For "2", XEN_DOMU is fine, although it would be nice if that
were as indistinguisable from GENERIC as possible.

> > *) unless we're talking about the shaken cocktail with equal parts gin,
> > maraschino, chartreuse and lime juice.
> 
> Heh, first time I heard from that one. Probably not the last, though ;)

the key is to use enough ice.


Home | Main Index | Thread Index | Old Index