Re: rump is complete

[Antti Kantee <pooka%cs.hut.fi@localhost>]

Hi,

Good questions, but no.  Since the confusion is common, I'll try to
provide some clarity.  I'll answer your questions in reverse order,
since it leads to a more logical progression.

On Tue Mar 22 2011 at 06:46:49 +0100, Christoph Egger wrote:
> > For what rump is, does, and how to use it, see the usual place:
> > http://www.NetBSD.org/docs/rump/

> Are the manpages also complete?  (me reading pud(4))

Pud is *not* considered a part of rump and is only tangentially related.
The same can be said about puffs (or any "FUSE-like" technology).

Pud is a microkernel-like server callback method which allows you to route
the bdevsw/cdevsw protocols to userspace and provide some implementation
for a block/char device.  In contrast, rump allows you to run unmodified
kernel code and access it mainly via three different protocols: syscall,
vfs/vop and a rump specific one.

To take an example, while pud allows you to hook up some implementation
of a crypto disk driver to your kernel, rump (with the help of pud)
allows you to hook up src/sys/dev/cgd.c.  You'll probably get a good
idea of the distinction by looking at the figure here (but you need to
imagine some term substitution):
http://www.netbsd.org/docs/puffs/rump.html

Pretty much the only real-world case I used pud for was hooking up a
USB 3g device to my 5.x laptop when only -current had a driver.  Too bad
that the DSL was connected before I got pppd working against that setup :/
(this was back when I was working on ugenhc).

These days I would do the above with rumphijack, since for me there are
less moving parts that way.  However, the important distinction is that
pud establishes a system policy for a devicemajor <-> implementation
mapping.  So while in the rumphijack model the process decides which
file to access when /dev/pahe is opened, in the pud model the system
decides which device to access.  This can be an important distinction
on multiuser systems.  Also, the puffs/pud method allows the hosting
kernel to see whatever is being served, e.g. in case you want to do a
host mount from a block device.

> That sounds like we can have something like Jails (FreeBSD) or
> Zones (Solaris).

Well, no: the rump anykernel model and OS level virtualization (i'll use
"jails" from now on) are completely different things.  They both allow
to virtualize namespaces, borrow certain host facilities and run code
natively, but that's where similarities end.

First of all, the point of jails is to dictate a policy for the guests.
This means that someone above has total control of what the guests
are allowed to do.  In contrast, like I already mentioned earlier,
anything providing a system policy is only tangentially related to rump.
rumphijack makes it possible to run unmodified applications against
services provided by a rump kernel, but that is application virtualization
instead of jails.  While with application virtualization you can fool
programs which are blissfully unaware of the virtualization layer (let's
say web browser viruses), you cannot protect against anything which is
intentionally trying to break the protection.

Second, jails aims to provide the illusion of a complete system for an
application or a virtual server, while rump aims to provide only what
is desired and leaves the rest to the host.  Even with helpful shortcuts
like rootfs cloning there's a lot of setup overhead for a jail if you want
your virtual environment to exist only for milliseconds.  The tradeoff,
of course, is that with rump you can virtualize only parts of the
system -- but those parts are the ones at least I am interested about
in the first place instead of the required overhead.

Third, jails requires explicit kernel implementation (be it via explicit
coding or kauth-like hooks) and executes everything in kernel space.
In contrast, rump requires no explicit kernel code (apart from a clean
component partitioning, which NetBSD pretty much had even before I
started) and leverages existing containers for virtualization (processes).
This means that if you have a kernel level programming oops "with" any
jail, you're completely toast, whereas with rump you can haphazardly
kill and maim and panic components as you wish without affecting the
host as a whole.

Fourth, and related to the previous one, with jails you run exactly one
copy of the code.  The rump model doesn't care about this, so you can
for example run virtual copies of kernel code with different compiler
flags/options or, to pick something more extreme, profiling guided
optimization and/or jitting.  Notably, you can make the memory/speed
tradeoff on a per-instance basis by using PIC libs or not.

So, in summary, neither technology is a substitute for the other one,
because they target different things.  For example, points 2-4 make
rump unparallelled (*) for kernel driver development and testing and
pretty much anything where you need a short-lived virtual copy of a
kernel driver.

  - antti

*) curiously, though, grimod de la reyniere's "unparallelled roast"
recipe does not feature rump

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa