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:
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.
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.
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.
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.
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.
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.
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>".
Personally I'd like to see disjoint drivers and operating systems. No single OS model solves all problems. Of course no driver code scales to unlimited uses, but at least steps should be taken to ensure that current driver code goes as far as it does. (Then again, I already did that, now just putting my mouth where my money went)
Can you expand on that idea? For Rumprun, it's not very many minutes of work to set things up so that you have a lower readonly file system layer (immutable across restarts) and then a memory file system on top of that (for purposes of applications insisting to modify "readonly" files). But, of course, it's not very many minutes only if you know the ins and outs of the backend system, and that's not the level of usability what we're aiming for. So, if writing "readonly" files is a widely desired feature, we should probably somehow support it as part of the general infrastructure in Rumprun so that it just works even if you don't know the ins and out of the underlying system.
Do you know anyone who's even tried to make Java work on Rumprun? I only tried Python, that worked out of the box. From what I've been following others, e.g. Erlang, Rust and Javascript (node.js) more or less provided the same experience.
Notably, there's ongoing work (with an already functional result) to run Mirage on top of the low-level drivers provided by Rumprun. The idea in doing that is enabling the "top-level" Mirage stack to run in environments for which they don't have native OCaml drivers yet. (disclaimer: I don't speak for Mirage, though I do speak for Rumprun)
"a" is sort of orthogonal to rump kernels, but yes, you can run at least file system drivers transparently as userspace servers (just give -o rump to mount(8)). I've also run a USB modem driver as a userspace server, in the "the kernel I'm running doesn't contain support, but a future kernel revision has" fashion.
For "b", rump kernels don't support "compiling out". Rather, the idea is to "link in" only what you need, as in "don't need file systems in that particular application? well don't link in VFS then".
I'm not sure if you're right or wrong, but maybe the rump kernel FAQ at http://wiki.rumpkernel.org/Info:-FAQ will straighten your thoughts. In the regrettable case that it doesn't, you can always suggestion additional questions.