Info: FAQ

Antti Kantee edited this page Feb 5, 2016 · 19 revisions
Clone this wiki locally

This page contains Frequently Asked Questions for rump kernels and the Rumprun unikernel. Propose new questions on the mailing list or to @rumpkernel.

Questions (with links to answers)

Questions and Answers

What is a rump kernel?

A rump kernel is a composition of componentized drivers. More specifically, a rump kernel employs a mechanism for taking an existing monolithic operating system kernel, leaving out everything except drivers, and using those drivers as library components. For example, depending of the set of components you pick, a rump kernel can provide you with PCI drivers, SCSI drivers, a TCP/IP driver, a POSIX system call driver or file system drivers. A rump kernel is agnostic to for example virtual memory and always runs on top of an external scheduler. Leaving the extra policy out makes a rump kernel lightweight and straightforward to integrate into any environment.

Why the name?

If you look up "rump" in a dictionary, you'll find a definition which involves the group that is left over after a portion of the contents of a larger group have been removed -- the classic example is a rump parliament. The attribute "rump" therefore establishes the relationship between just a kernel and a rump kernel.

What problems do rump kernels solve?

Drivers are necessary for software to be able to interact. For example, device drivers allow interaction with hardware, a TCP/IP driver allows interaction with the internet and file system drivers allow interaction with storage formats. The challenge with drivers is that you both need a lot of them, and they have to be "bug-compatible" with the real world. While writing drivers is straightforward, making them bug-compatible with reality is an insane undertaking. Rump kernels solve this problem by giving you a plethora of real world compatible drivers which you can then use in whatever way to see fit without having to include the baggage that an operating system would load you with.

What is the anykernel?

The anykernel architecture allows creating rump kernels from unmodified monolithic kernel codebases. In other words, the anykernel answers the question of where the driver component for the rump kernels come from. It takes work to convert a monolithic kernel into an anykernel. In essence, turning a monolithic kernel into an anykernel is akin to the process of making the kernel SMP-scalable: lots of small, judiciously applied changes which all work towards a goal.

Is a rump kernel the same as an anykernel or unikernel/exokernel/$otherkernel?

No. The terms are distinct for the simple reason that they refer to different concepts. If you want to know more about the concepts revolving around rump kernels, see e.g. here.

Where can I get a full and correct technical description of the concepts?

See http://book.rumpkernel.org/. Notably, like books in general, it describes a snapshot of the world at the time of writing. The fundamental concepts have not gone out of date, but the use cases and motivations have widened.

Why not simply use an operating system?

There are many reasons, e.g. security, footprint, resource consumption, understandability, tunability, etc. In general, why use anything which does not give any benefit? However, without drivers you do not get very far, so it used to be "OS or bust", and that is probably why you are conditioned to thinking that you need an OS.

Why is there so much stress on the drivers being unmodified?

As explained above, the problem with drivers is that you need so many of them these days, and they also need to work in the real world. The first problem with modification or porting of drivers is that you need to do the work, and also you may not introduce any bugs while doing so. Now, let us assume that you happily maintain your own modified versions of drivers you ported from somewhere. Then, at least one of the following is true:

  • You have a very specific use case target and can afford to pick a very small subset of drivers to maintain.
  • Your organization has developer time to spare for tracking upstream security fixes, new features, etc.
  • You are willing to accept that you might not have the latest security fixes and features at all times.

None of the above hold for the rump kernel project. Therefore, we rely on unmodified drivers we obtain thanks to the anykernel. We do hope that you can also use the drivers provided by rump kernels as unmodified components, and therefore escape the maintenance penalty. Of course, no code scales infinitely, and "unmodified drivers" cannot be used as an all-encompassing mantra. However, they key is to avoid modification unless absolutely necessary, thereby avoiding unnecessary work and unnecessary pain.

What is the Rumprun unikernel?

We will assume that you know what a unikernel is. The Rumprun unikernel consists of rump kernel components glued on to a very simple low-level bootstrap and scheduling layer. Rumprun also supports an optional libc and a POSIX'y application interface. The strength of the Rumprun unikernel stems from, again, unmodified drivers. Since the drivers used in the unikernel stack are unmodified, both I/O devices (network, storage, etc.) and POSIX applications will work like under a regular OS. However, you still get unikernel benefits.

What type of programs work on the Rumprun unikernel?

Most applications will work, and now we just have to define "most". For simplicity reasons, the Rumprun unikernel does not support virtual memory -- unnecessary in a unikernel -- nor does it support signals the traditional way. That means that programs which absolutely depend on things like fork(), execve(), mmap() and sigaction() may not work correctly. In some cases we provide a small amount of cheap emulation for common cases (e.g. mmap(MAP_ANON)), in other cases we hope that applications which truly wish to be Rumprun-compatible will be modified to better suit the paradigm. Yes, we could add virtual memory support, but we choose not to, because we would rather concentrate on running 90% of existing applications really well instead of running 99% of existing applications in a mediocre fashion. If your application absolutely needs virtual memory or some other "full OS" feature, you probably should run it on a full OS instead. If applicable, you can always consider building your own, application-specific OS on top of the drivers provided by rump kernels.

If rump kernels are a framework project, why are you building a product with the Rumprun unikernel?

Since it is difficult to "sell" a framework unless people can evaluate concrete use cases, there were some efforts to show that rump kernels can run in various environments. Then we simply noticed that adding an application environment on top of the rump kernel was trivial, applications "just worked", and furthermore there was demand for a unikernel which could run legacy applications out-of-the-box. So, to be honest, building one was mostly an accident, but it worked out really well.

Can you compare and contrast rump kernels with other generally related technologies?

Sure, we have a separate wiki page for comparisons.

What is RUMP?

It is a early backronym that has not been used in any official context since early 2010, don't use it. "Rump kernel" shall be the name of the technology, and the technology's name shall be "rump kernel". "RUMP" shalt thou not use. Neither shalt thou use "rump", excepting that thou then proceed to "kernel". "R.U.M.P." is right out!

Is there a logic to the use of lowercase and uppercase in the names?

Yes. The terms "rump kernel" and "anykernel" are concepts and are written in lowercase, just like for example "monolithic kernel" is. In contrast, "Rumprun" is the proper name of our unikernel, and is written in uppercase, just like for example "Linux" is. Beyond that, most things are written with lowercase, since it looks more programmery and doesn't require the effort of pressing the shift key (buildrump.sh, rumpctrl, drv-netif-foo, ...).

Are rump kernels multiprocessor-ready?

Yes. However, if you can partition your workload so that you need to max out only one core per software stack, you can automatically optimize away costly atomic memory operations and cache coherency issues at the application level disappear. So, even though rump kernels support SMP, the recommendation is to try to avoid that 1990's software architecture and partition better -- unlike with traditional OS kernels which conflate the OS and drivers, you can run a rump kernel instance per driver. For example, the Rumprun unikernel does not support SMP, again because of simplicity reasons.

Does a rump kernel support fork and exec?

Yes ... but this discussion gets complicated quickly. Since a rump kernel is a rump kernel, it does not implement fork and exec. However, a rump kernel can correctly deal with remote applications forking and exec'ing. Forking a rump kernel itself would be a conundrum even in theory: consider e.g. the case where post-fork there now is two entities servicing the same IP address. If the discussion got too complicated too fast, and you want to know more, check out the gory details from http://book.rumpkernel.org/.

What sort of licenses are rump kernels and the Rumprun unikernel available under?

The project license is 2-clause BSD. We include a variety of free+open software components written by others. Those components are predominantly of BSD/ISC license (but not exclusively!). Since rump kernels are intended to be applicable for static linking into arbitrary environments, we do not include GPL in the core. You are, of course, free to choose your favorite license for any project in which you use rump kernels.

A detailed per-driver license is available at least from the web page of the Debian package for rump kernels. Note: while we are very thankful that such a listing exists, we make no guarantees about it being perfectly correct. Where pertinent, it is your [legal department's] responsibility to verify the list against the actual licenses found in the source modules.

How can I/we support the rump kernel project?

The best way is to use what we offer, and send feedback. The most valuable feedback comes in the form of bug reports -- we can only fix problems we are aware of. Patches are optional. Beyond that, tell your friends and colleagues about your experiences ... especially if they are positive ones, which we hope they are.

Can I/we support the project financially?

Yes. However. At the time of writing this, the project is not a legal entity. You can indirectly support the project by hiring a consultant e.g. to work on a feature you crave. If you desperately want to make a "no strings attached" donation, contact donations@rumpkernel.org.

How do I/we contribute code back to the project?

See the contribution guidelines.

Can you suggest some projects?

Suggesting a project is difficult, because unless you are scratching a personal itch and just doing something for the sake of doing something, your motivation might not be high enough for successfully completing the project.

If you want to develop such an itch, probably the easiest way is to add your favorite software to the Rumprun packages collection. By doing so and deploying your software, you will no doubt notice room for small improvements here and there. Before long, you will be swimming in projects.

What do I do if I just want a feature without the money to hire someone or time/skillset/etc. to implement it myself?

File an issue report. If it's a widely desired feature, someone will most likely get around to implementing it eventually, and the chance of the implementation happening sooner will only increase if we are aware of users in need of said feature. First and foremost we are a no-strings-attached free/open source project. If nothing else, we guarantee that you get at least what you pay for ;-)