tech-kern 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