Regarding unikernels it is fun to combine it with Erlang, since Erlang already has process isolation by default, so it acts as a mini-OS for your application. Process supervision is a bit like the initd (or systemd), it has networking and file system access API,etc...
> That minimal quality of most of the OS not being present also explains why the container the drivers run in is called a rump kernel
I have seen a number of articles on 'rump' kernels and they always similarly gloss over the name like this. How does that explain? It's not capitalized, so I assume it is not an acronym that stands for something.
Where does this name come from? Is it an acronym, portmanteau, metaphor, what? I have never seen it clearly explained, and I have followed link trails down the rabbit hole through circular references and wikis looking, half a dozen times at least, to no avail.
When you don't know what a word means, the best place to start looking is usually a dictionary. For example, Merriam-Webster's definition 3:
a small or inferior remnant or offshoot; especially : a group
(as a parliament) carrying on in the name of the original body
after the departure or expulsion of a large number of its
members
> Where does this name come from? Is it an acronym, portmanteau, metaphor, what?
It appears to be a fairly standard use of the English word "rump" in its non-anatomical sense, that is "a small or unimportant remnant of something originally larger."
You win the gold star, that was the historical context of this usage of the word that I did not understand and what I was missing, mystery solved. Thank you!
"An anykernel can be instantiated into units which virtualize the bare minimum support functionality for kernel drivers. We call these virtualized kernel instances
rump kernels since they retain only a part of the original kernel."
This is an example of canonical documentation doing exactly the same thing I just described. I am no more enlightened about what a "rump kernel" is than before I read the paragraph.
Is the implication that we're tossing out the head, neck, loins, bones, organs, etc. and only the delicious bacon of the original kernel is kept? The rump is the part?
The principle of a rump kernel is to make OS drivers and subsystems able to run both in a monolithic kernel context and in a userspace context, with a microkernel-like fashion.
An earlier example of a similar approach is DDEKit (https://os.inf.tu-dresden.de/ddekit/), designed so that Linux 2.x drivers can be reused in foreign systems. It's what GNU Hurd uses for its TCP/IP stack, for instance.
I'd love to see a Smalltalk VM running directly on Xen. The language has always been a bit awkward on PCs because in its heart it still wants to be the OS for a Xerox Alto. It ought to be right at home on virtual metal!
Here's a prediction of how this conversation is going to go:
1. This stuff isolates specific functionality into a hardened component!
2. You can run an existing program as an isolated, hardened component!
3. You can run all of your programs as iso., hard. components! The parts of your system won't be able to step on each other except in well-defined ways!
4a. You mean sort of like old-school process isolation?
4b. Blah, blah, blah, Plan 9, blah...
4c. Blah, blah, any virtual machine like the JVM...
So there is:
http://erlangonxen.org/
code: https://github.com/cloudozer/ling
Basicly instead of:
hardware|kernel|os|erlangvm|yourcode
it is now:
hardware|xen|ling|yourcode
Not sure how functional it is now. I haven't followed the project in the last year much. But I see some development on github lately.