Running Rust on the Rumprun Unikernel | Hacker News Reader

Running Rust on the Rumprun Unikernel

gandro.github.io

Well done!

It'll be interesting to see what space unikernels take up in the coming years.

I think there is still a lot of fruitful territory to be explored in this space as traditional multi-user, multi-tenant assumptions can be thrown out the window. I think a big, unexplored advance that unikernels might be able to offer is the ability for the kernel-part to peek into the guts of what its programs are actually doing (at compile or run time) and make broader assumptions about scheduling.

It would probably be the other way around, the programs making their own fine-grained policies from primitive kernel mechanisms. This has been an area of research for decades.

Multi-tenant assumptions probably aren't going away, since mainstream systems have by and large not been able to handle them.

In this case I meant that something of a runtime or additional code could be tacked on to programs when the compiler and/or run time sees that a program only computes in response to input, for example. In the case of unikernels, distinguishing parts of the "system" is an arbitrary line.

Speaking of Rust - is anyone running Rust in production apps yet? Now that Rust has reached 1.3.0, it's perhaps not unlikely.

https://doc.rust-lang.org/complement-lang-faq.html#is-anyone...?

Clickable link :-p

https://doc.rust-lang.org/complement-lang-faq.html#is-anyone...

We did an interview with our production users a few months back: https://internals.rust-lang.org/t/production-user-research-s...

Names you might have heard of: Dropbox, Skylight.io, Sandstorm.io, Tessel, Terminal.com, Chef, among others.

Thanks! Could you possibly please update the FAQ with all the recent users?

We're in the middle of COMPLETELY re-doing the FAQ, actually :)

Great work! I'm so glad this has been done. I think seeing OCaml used with Xen made me realize how great Rust could be in this context.

I would like to hear more about what things are unsupported. For example, rump kernels do not have fork, so obviously if you expect you application to fork, it will not work. But there are other, more subtle caveats.

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

What kind of embedded devices could this be booted with?

Anything that can run FreeBSD and then some? I don't know.

NetBSD, not FreeBSD.

Rumprun doesn't require (or support) virtual memory, so granted enough memory (a few megabytes), it can work on embedded systems.

Rumprun currently runs on x86 and x86-64, support for RISC-V and ARM is in the making. The architecture specific code is quite small, you just need to make sure that NetBSD (and Rust) support your architecture as well.

Great news!

Reply on news.ycombinator.com