As someone who forcibly steered himself away from the temptation of a toy OS side-project due to the enormous time investment in drivers, syscall handlers, and so on that it would have taken to get working, I can't possibly thank you (or curse you) enough for calling rump kernels to my attention. So instead I offer a minor nitpick:
> If you do the math (and bc did), there are 86400 seconds in a week.
"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."
-Charles Babbage
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
The author's command of the English language easily trumps any deficiencies in multiplication. His little quips crack me up. "All that and a can of paint."
"Rump" is just a cool name in my opinion. I liked rump(3) before I even knew what it did. Naming and coming up with clever acronyms that are not annoying is difficult. Props to the author for that alone.
Whereas something like "Docker" makes me cringe. No matter how good it is. Some of these names people come up with are just terrible.
Anyway, we know that rump can be used for mounting filesystems (e.g., ones containg applications) that reside on USB sticks or other removable media. By using rump_ffs, there is no kernel panic on errors associated with the mounted filesystem. For that one use alone, nevermind its otherwise enormous potential, I'd say rump is worth the rumpification of the NetBSD source tree. It is not easy to crash the netbsd kernel, but filesystem errors are one way to do it, in my experience.
I think the author should have at least one article about rump that uses a certain song title from Exile on Main Street.
Oh oh oh oh! This is exactly what I've been looking for! And from what I can see it works on ARM too? Amazing! I've been working on a toy kernel in my spare time to learn bare metal stuff, and this will be perfect to give me a leg-up to doing real work with it.
Yes, works on ARM. The only architecture-specific support that a rump kernel needs is cache-coherent memory operations, and those are necessary only if you want to run on a multiprocessor system. So works on anything to which you can compile C code, really (though you might have to toy with some Makefiles a bit for new architectures).
MirageOS, at least from my viewpoint, is trying to figure out what the cloud software stacks of tomorrow should look like. Rump kernels give you production quality building blocks for running existing code today in any environment. I wouldn't compare the two projects too much.
I see MirageOS as an OCaml Machine, it doesn't let you develop applications within itself in the way that a Lisp Machine does but maybe that doesn't make sense for OCaml.
The two projects are very complementary. You could easily write a MirageOS rump kernel backend that linked to the kernel device drivers, and build higher level services (HTTP, TLS, XMPP) in OCaml that use the production-quality NetBSD device drivers.
You need to expose a hypercall interface for this. Can anyone explain how that would be implemented, and does it restrict the kinds of kernels you can write? e.g. can I create a unikernel or microkernel with this?
Unikernel: yes, that's what the article mostly describes.
Microkernel: yes, though strictly speaking you'd use rump kernels for the servers in a microkernel OS. (that was actually the first use case back in 2007)
There are multiple example implementations for the hypercall interface ("rumpuser") at http://repo.rumpkernel.org/
You can find full details from http://book.rumpkernel.org/ (it's a bit out of date in describing what has been built using rump kernels, but the parts describing basic functionality are accurate).
> If you do the math (and bc did), there are 86400 seconds in a week.
you might want to check bc's math ;)