An Internet-Ready OS From Scratch in a Week – Rump Kernels on Bare Metal | Hacker News Reader

An Internet-Ready OS From Scratch in a Week – Rump Kernels on Bare Metal

blog.netbsd.org

123 pointszdw23 comments

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.

you might want to check bc's math ;)

Working 24 hours a week makes you more productive. So he did his math ;)

There's 86400 seconds in a day. There's 604800 seconds in a week.

Read huuu's post again ;)

And what about the weeks in which a leap second was added?

Yes!

There are lots of reasons why my hobby operating system project has been abandoned, but device drivers was one of the biggest reasons.

I've been planning to revive my kernel programming projects and when I do, I'll definitely take a look at rump kernels and the BSD device drivers.

$ bc

606024*7

604800

Heh, I suspect "the author" missed a digit when inputting the calculation. bc needs a calculate-what-i-meant mode!

60 * 60 * 24 = 86,400

60 * 60 * 24 * 7 = 604,800

"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

Nice to see rump make the front page again.

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

This makes me think of MirageOS but with more drivers and I don't have to learn OCaml.

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.

It's all good fun in library OS land :)

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?

There is a Xen version with a hypercall interface already https://github.com/rumpkernel/rumprun-xen

There are microkernels using the rump kernel code, eg Genode.

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

503 Service Unavailable... anyone have a copy? It's not on wayback machine yet.

http://www.iki.fi/pooka/private/baremetal/art.html

It doesn't contain the pretty css, and I probably fixed a tyop or two when posting, but the content should be 99.9% same.

Thanks, much appreciated!

Reply on news.ycombinator.com