[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Lightweight virtualization - the rump approach
Some of you have probably noticed a posting of mine on TNF blog 
regarding Antti's work (rump) in NetBSD . After discussing it briefly
with him via mails, we chose to bring the subject to a wider audience;
so here it is.
To sum up a bit the situation, some of you have probably seen a trend
towards "microkernel"-like approach to improve system availability,
resilience, or security.
By "microkernel-like" approach, I mean:
- consolidating different general purpose OS above some kind of
microkernel, like Xen,
- security through isolation, target being desktop, like Qubes (COTS
with Xen, Linux, IOMMU, etc.)
- specific microkernel architecture of the embedded world (many, many more).
The thing is not new. I guess that the increase in performance of
today's hardware made it more attractive, as well as the need for
stronger security, especially for kernels, with MILS systems in mind .
I am not posting this to reinstate the decades old monolithic vs
microkernel troll, so please avoid that field; thanks.
Lights on the work of Antti, with rump. Most systems I have seen lately
provide the characteristics enumerated above by pulling in a general
purpose OS, like Linux, with its environment, just to get a specific
need, like an up-to-date network stack (strong push for IPv6, anyone?),
drivers (filesystems, usb, pci stacks, devices), etc. There is no real
componentization in mind.
Everything being virtual these days (see cloud computing buzzwords, or
hardware systems delivered with some kind of hypervisor inside - PS3, or
sun4v, for example -), I see Antti's work (well, all TNF work too ;) )
as being a real asset to make the NetBSD's code base more widely known,
appreciated and used. I have yet to see a solution where you could port
then debug kernel code directly to userland (at least, for a general
purpose OS), or offer an alternative when you need to port specific
components, like network functionality or filesystem code.
For this reason, I have a few questions for the ones familiar with rump
technology here, especially:
- the basic architecture; how did/do you achieve such a functionality?
Adding an extra layer of indirection within the kernel? Suppose we have
improvements in one part of it, like TCP, IP stacks, could it directly
benefit the rumpnet component, or any service sitting above it?
- What kind of effort would it require to port it to other OS
architectures, especially when the API they offer could be a subset of
POSIX, or specific low level API (like Xen's hypercalls)? (closely
related to the work of Arnaud Ysmall in misc/rump )
- If rump could be used both for lightweight virtualization (like rump
fs servers), or more heavyweight one (netbsd-usermode...)?
- eventually, extra icing on the cake, especially with the appearance of
IOMMU in common x86. Could rump be used for (device) drivers to offer
better isolation and cause less harm to the kernel?
Thanks to all who responds, and please, avoid flaming on that one. I'd
like to keep the discussion on technical grounds.
Main Index |
Thread Index |