IMHO, this is the most useful systems paper ever written. Rump kernels were designed on the listed principles. (if the implementation managed to follow the principles is of course another matter ...)
There's a growing number of users, but they aren't centrally collected. I've actually thought about creating a "Who uses rump kernels" page, but haven't gotten around to it. No better time than now to do that:
Thanks for letting me know. I have to avoid people like you. I have tons of HW and I can never finish it because I drown in all the interesting system design and articles here. GO AWAY! Haha.
If I had a time machine, the first thing I'd do is s/rump/& kernel/ in all old writings. The second thing I'd do is make a case for writing creat with an e.
Wow that's ugly. The original regex is a valid POSIX BRE; it also works in GNU sed and FreeBSD sed with default options. But maybe your translation will be useful to others who only grok PCRE.
The original version isn't actually valid POSIX BRE. It's a sed specific meta-character that is specific to sed and won't work anywhere else [1]. It's not part of POSIX BRE (which doesn't cover substations anyway). The zero width positive look behind is common to many more languages than just sed for doing that substitution. There is one version that will work in all of them, s/rump/rump kernel/, but it repeats the first word
If it's not an instance of a selection of components running on top of externally scheduled threads, it's not a rump kernel in my book. So, strictly speaking no, but the answer really depends on what you want to convey by "basically". Many of the use cases should fit both projects.
I don't know enough about rump to talk more definitively, and in fact I've failed to find an overview about what it is technically, how it works on NetBSD, how it works outside NetBSD, etc. Does running rump on Linux provide the SMP scalability improvements one misses with NetBSD's kernel for instance? Can you point me at something to read that's short enough to digest in an hour?
Follow the "Getting Started" link on rumpkernel.org. That page includes both short and long reading (should you get more interested ;), and also some "hands on" tutorials should you learn about things better that way (I know I do).
SMP scalability is all about bottlenecks. If the driver is the bottleneck, it won't scale no matter where you run it.
What porting? We have quite a few pieces of software in rumprun-packages which require ZERO (0) porting or patches to function as unikernels, e.g. haproxy, mpg123 and php. Feel free to check them out for yourself if you don't want to take my word for it.
My 'editability' timed out on my initial comment before I had a chance to fix that, Antti.
That said, there's a footnote about rumprun, and if Justin Cormack of Unikernel is https://twitter.com/justincormack, its all so close to Antti (Justin and Antti are both of NetBSD). For -me- Antti has been such a big part of my unikernel experience, I figured there'd be more involvement in this project or at least more recognition of his work.
I sort of agree with you and I sort of don't. For example, I think an interesting future path for the Rumprun unikernel (which, I always stress, is not the same thing as a rump kernel) is running without the POSIX-y userspace interfaces. In fact, that's pretty much where I think e.g. Golang support for Rumprun should go, i.e. remove the userspace abstractions from the stack, since they, conceptually, do exactly nothing. Parts of the implementation of Rumprun are wrong, because I didn't previously see the importance of no-userspace, but I'm slowly converting those. (ironically, Rumprun -- before the codebase was even called Rumprun -- started out as no-userspace, and then grew too much userspace ... but that's really another story)
(edit added later so that we get credit going where it's due: It occurred to me that it was Sebastian Wicki who was campaigning for the no-userspace mode last summer as part of his lowRISC project, and did the initial work to be able to again use Rumprun without "userspace". Apparently my memory of events goes only a few weeks back if I don't think about things carefully ...)
Now, if I'm allowed to summarize rump kernels, I'd say the goal is to build a framework which incorporates enough of the past to allow things to work, but tries to be as flexible as possible so as to enable the future. I'm a firm believer in "there's no such thing as #1", which means you shouldn't produce software components which work only in one type of tool, because it's easy to foresee that right around the corner you'll have to build components for the next tool.
p.s. "Atti"? That one was new, usually it's "Antii" or something like that ;) ;)
However, you can use rump kernels as a major component of a unikernel implementation. A rump kernel provides environment-agnostic drivers, meaning you can integrate them pretty much anywhere.
Now, what is a unikernel? From my perspective it's essentially:
1) application
2) config/orchestration
3) drivers
4) nibbly "OS" bits
So from the bottom, the nibbly bits include things such as bootstrap, interrupts, thread scheduler, etc. It's quite straightforward code, and a lot simpler that the counterpart you'd find e.g. in Linux. But you can't do much anything useful with the OS when that part is written.
Drivers are difficult because you need so many of them for the OS to be able to do much anything useful, and some drivers require incredible amounts of effort to make them real-world bug compatible. Just consider a TCP/IP stack -- you can write one from scratch in a weekend, but the result won't work on the internet for years. Then you may need to pile on a firewall, IPv6, IPsec, .... A rump kernel will provide componentized drivers for free. The policy of if you use those drivers in a unikernel or microkernel or whateverkernel is up to you, but I guess here we can assume unikernels.
The config/orchestration bits are actually quite an interesting topic currently, IMHO, at lot of opportunities to make great discoveries. Also, a lot of opportunities to use the rope in the wrong way.
The applications depend on what sort of interfaces your unikernel offers. If it offers a POSIX'y interface, you can run existing applications, otherwise you need to develop them for the unikernel.
Now putting rump kernels and unikernels together: the nibbly bits are straightforward, the drivers come for free via rump kernels, and those drivers provide POSIX syscall handlers, so POSIX'y applications just work. That leaves the config/orchestration stuff on the table. There's a rumpkernel-based unikernel called Rumprun available from repo.rumpkernel.org. It's essentially about solving the config/orchestration problems. Due to the rump kernel route, the other problems were already solved in a way which can be considered "good enough" for our purposes.
Hope that clarified the difference between rump kernels and unikernels.
With gdb, prints, and lots of thinking. In other words, pretty much like you'd debug one elsewhere, except instead of "run" in gdb you need "target remote <guest-gdbserver -address>".
When all of the "kernel" exists to service that single application alone, does it matter? Where does the kernel start and the application/libraries end? Who says that a protection barrier is even best suited for every application at what is typically the syscall level?
Yes, you can add protection barriers (at least if the underlying HW supports it), but I have trouble imagining what you'd really gain. Maybe, if we assume the cloud, if you restrict the hypercalls to the "kernel", you can add some extra fences an attacker would need to go through to attack the hypervisor, but that barrier would not be at the normal user/kernel separation in a general purpose OS.
