anttiok

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:

http://wiki.rumpkernel.org/Info%3A-Who-Uses-Rump-Kernels

(don't expect it to be highly populated yet, I just created it and seeded it with the project I'm affiliated with)

Correct.

links with some more information on a conceptual level: http://wiki.rumpkernel.org/Repo#the-big-picture http://wiki.rumpkernel.org/Info:-FAQ

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.

That, and my name not being Antii (as already mentioned in the discussion).

Pick whichever reason suits your agenda ;-)

Assuming that was directed at me, what's "the comment"?

Anyway, that's the right direction if that's what you want you want to accomplish. Otherwise it's the wrong direction.

sincerely, anti

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 ;) ;)

No, a rump kernel is not an unikernel, check the FAQ linked from http://rumpkernel.org/

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.

(edit: minor formatting fix)

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)

We have at least redis in rumprun-packages -- https://github.com/rumpkernel/rumprun-packages/tree/master/r... -- which AFAIK was packaged based on a non-toy need.

Yes, the need for persistent storage for persistent values is quite solid ;-)

Ah, yes, I definitely remember you and your work, just didn't realize it was the same person.

Hop on to irc again some day or start a thread on the mailing list, and we can brainstorm about the best solution.

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.

I think we're in rough agreement.

"The author's" assumption is that getting rid of unnecessary moving parts is an improvement. Having many slightly different copies of the same functionality in the stack is not redundancy, it's just silly -- "all problems with operating systems can be solved by removing layers of indirection"

I'm not too worried about companies selling tools instead of computers, just like I'm not upset upset that I didn't get a metallurgy plant when I bought a hammer. Yes, the philosophy of computation is a different thing (as Dr. Kay often points out), but sometimes you just need a tool instead of poetry. (nb. I'm not making a statement about whether or not everyone should understand computers)

Maybe if you think about a driver as a unit which performs a computation, the article will make more sense. I like to call drivers "protocol translators", but translating a protocol from one representation to another is really just a computation. The idea is to slowly liberate those units of computation from the clutches of the "centers", and then improve them, while still keeping the world functioning.

The folks at genode.org are also relying on capabilities for the system. Maybe they have some ideas on how to relate it to application/service programming, and more importantly, how to get from current reality to "good enough"?

I think the last two paragraphs of "Conclusions" are the most interesting part of the thesis.

(author. thanks for the kind words).

I think desktop-style devices are going more in the direction of being personal. And where they aren't, probably in the majority of cases you don't want the OS to mediate access poorly. I'm not saying that there aren't any counterexamples, though.

What you say about running processes "on behalf of you" is really quite interesting. There is no reason you should trust the application programmer to get it right, yet that's what the OS currently gives -- you can run your db as user "db" and httpd as user "httpd", but it doesn't do much good in terms of the actual user. So, some radical thinking is required. The editor of ;login: actually tried to point me in the direction you mention when we were working on the article, but I couldn't formulate clear enough thoughts on the subject to include in the article. Maybe someone else here has already thought about it and can put it into writing?

Your statement "rump kernels do not have fork" is not entirely accurate in the context. Rump kernels do support fork. However, it is not conceptually a rump kernel's business to provide fork. So it's actually the Rumprun unikernel that does not provide fork here. It's a small but quite important distinction, because it means that if you wanted, you could take the upper part of the stack and bolt it on to some other simple bottom layer which does support fork. I certainly don't want to, but maybe someone else does.

Anyway, you are right, not everything is supported. It would be cool to know if a valid program will work on Rust+Rumprun without having to run it, but I can't imagine a simple solution to that problem. I guess if the problem of knowing if something will work without running it were solved, programs wouldn't have bugs ;)

The community didn't reinvent "ASIC". It was my joke, but humour is difficult ... Read the conclusions of my dissertation. Then realize that the cloud is just one form of special-purpose hardware. Then be me trying to tongue-in-cheek claim that I foresaw the potential of rump kernels on the cloud 4 years earlier. Then maybe the joke will be funny. If not, well, you don't get your money back, sorry, your only condolence is that I rarely use the same joke twice.

I still don't see too much similarity between DDE and using full-OS VM's to act as DDE backends. It's like observing that unikernels and traditional timesharing operating systems can both run applications, so they're similar. Yes, but ... Anyway, I understand what you mean, disagree, and don't think it's worth debating further.

Yea it took a while. I often joke that it took two weeks to get things working, and four years to make it maintainable. In reality, the first version did take two weeks, but maintainability grew with completeness and correctness. It also took several years to get people to stop telling me I've reinvented FUSE (which I did, but not with rump kernels ;). If you're interested, I recently touched on the early history and original motivation in this blog post: https://blog.xenproject.org/2015/08/06/on-rump-kernels-and-t... I am absolutely certain that we'd not be having this discussion if kernel driver development had not been the original motivation. That's the buy-in for the upstream OS.

See the community link at rumpkernel.org if you want more non-false information. One of the problems with "related work" is that you're trying to find some difference to your own work to justify the publication of your paper, and all that without fully understanding the related work. So you tend to make goal-driven assumptions, and hence "related work" generally tends to be more wrong than right. The exception is really well-known work, because mis-assumptions about it won't get through the PC. But then again, telling everyone what they already know is not that useful, is it? At least for myself, writing "related work" was always the hardest bit.

btw, my papers are somewhat obsolete, the dissertation is still mostly accurate, even if the use case descriptions are out-of-date. So, I'm sure someone could 100% accurately cite an old paper of mine, and still completely misportray the current state of the art, because there's no "obsolete by" for papers.

I never saw the LeVasseur paper as being in the same category as e.g. DDE. It was one of those "don't fix the OS, just throw (virtual) hardware at it" approaches. Not saying it's wrong or right, just completely different IMO. Though, if you're trying to get rid of the OS -- like we are now, but not back then -- it's a weird approach ;)

Not sure if you can manually manage a research database. Are we really not able to do that automatically in 2015, or is it just a question of nobody building the right kind of crawler/searcher? After all, a manually managed index is a fork of the actual information. The other problem is that most research tends to be conducted with a "graduate-and-run" method. The professor might have a more holistic vision, but the professor lacks a) time to engage in such discussion b) a grass-roots understanding. But if it can be made to work, would be quite valuable.

Not to downplay the prior art, but I'm not sure I can call rump kernels an evolution of the previous work. I certainly hadn't heard about OSKit at least in 2009 (since it's not cited in my 2009 USENIX paper), despite going through several rejections with program committees for rump kernels since 2007. I first heard about DDEKit at my FOSDEM 2011 presentation when someone asked about the differences between rump kernels and DDEKit. I don't know if me being ignorant is more embarrassing for myself or the general computing community.

I do know that even my first [rejected] paper on rump kernels from 2007 stressed the idea of not forking. Of course, I was young and stupid(er) back then and didn't realize that academic program committees couldn't care less about if something actually worked or not, as long as you could generate nice graphs out of it.

Yes, I absolutely believe that drivers should be separate from the OS layer. Them being bundled together is a (pre)historic mistake. I agree that we would be in a much better place if projects like OSKit and DDEKit had gotten attention early on.

The point of rump kernels is not leveraging the whole stack from $OS. It's leveraging the unmodified drivers from $OS without the wholesale import of policies from $OS.

Sure, driver kits are an old idea, but starting from OSKit in the 90's the common fault is that the kits are forks over upstream. Forking is easy, but forking means that maintenance is unbearable unless you happen to be an organization with person-years to spare just to keep up with bugfixes and new features from upstream. Figuring out how to do it without forking (i.e. anykernel architecture which enables rump kernels out-of-the-box) takes more effort, but wins long-term. "proof": DDE is for Linux 2.4/2.6 drivers. NetBSD source tree from a second ago gives you rump kernels.

[I'm the author]. The core tech description is still (mostly) valid, but the general ecosystem has exploded far beyond what is discussed in the thesis. See http://rumpkernel.org/ for a description of current reality (and http://book.rumpkernel.org/ for ongoing work to produce an updated version of the thesis).

Check out the "Comparison with other unikernels" section in the post.