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
