[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Lightweight virtualization - the rump approach
On Sun, 16 May 2010 16:09:03 +0300, Antti Kantee <pooka%cs.hut.fi@localhost>
> On Sat May 15 2010 at 22:41:29 +0200, Jean-Yves Migeon wrote:
>> Let's take an example; suppose that $somefs_support is integrated in
>> NetBSD (like ZFS, NILFS, ...), what kind of additional work is needed
>> go from mount_somefs to rump_somefs (thinking about all _KERNEL
>> functions that are missing).
> Well, first of all you're falling into the microkernel two-faceted trap
> again with your example ;)
> rump_somefs is the *userspace* part. Actually, all the rump_somefs are
> somewhat misnamed. I think p2k_somefs would be a better name, but it's
> not really worth changing anymore.
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
>> >Well, maybe. That does make some sense if you already are capable
>> >of hosting domU's. I never found Xen very convenient for my use case
>> >(occasional testing) because it needs a special dom0 kernel. Why
>> >that stuff in GENERIC again? IIRC there were some device support
>> >years ago, but do they still remain?
>> At least for x86, key parts of MD code are handled differently,
>> especially pmap(9), locore's boot stuff, and some bus_space code. So
>> have #ifdef/inline thingies, which are, as you have noticed, not that
>> well modular-friendly.
>> Making this MD part dynamic would need some clean up in x86+xen, and
>> probably introduce function pointers to make the thing more dynamic and
>> "stable", like Linux and the big paravirt_ops.
>> dom0 vs domU is another story, it is basically a reduced version of
>> dom0, cleaned from all drivers and code that are not required for a
>> domU. May become unnecessary when kernel becomes more and more modular:
>> -rwxr-xr-x 1 root wheel 11M Apr 28 09:21 netbsd_XEN3PAE_DOM0
>> -rwxr-xr-x 1 root wheel 4,1M Apr 28 09:21 netbsd_XEN3PAE_DOMU
> 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).
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
> *) 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 ;)
Main Index |
Thread Index |