[Animats]

Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch and release" OS development.

Yes, you take a 20% or so performance hit for using a microkernel. Big deal.

At one time, you could download the QNX kernel sources and look at them.[1] This would be helpful in getting the microkernel architecture right. It's very hard to get that right. See Mach or Hurd.

[1] http://community.qnx.com/sf/sfmain/do/downloadAttachment/pro...

[naasking]

L4.sec is already formally verified. So the microkernel is already done. You need the user land services to provide POSIX compatibility, and that you can possibly do in Rust.

[steveklabnik]

https://robigalia.org/

[naasking]

Looks cool, thanks. They should take the opportunity to fix a few Unix/ACL security problems though, instead of just reproducing the same old POSIX quagmire. Make chroot isolation complete with plan9-like private namespaces, don't implement the traditional broken user/group security model and instead learn from the Polaris virus safe computing prototype (they're already partway there by using the capability secure seL4 kernel).

I would personally also want to eliminate a lot of the duplication in the POSIX API, but that probably won't fly. Can have your cake and eat it too.

[CUViper]

Redox may be exactly what you're looking for: http://www.redox-os.org/

And there are others: http://wiki.osdev.org/Rust

[Animats]

Redox is close, but they have pipe-like, rather than call-like, interprocess communications semantics. That means another layer of overhead. More important, it breaks the tight integration between scheduling and interprocess calls required to make a message-passing OS work fast under load.

Here's the QNX architecture document on this, which discusses how message passing and CPU scheduling integrate.[1] Microkernel designers need to read this very carefully. A good test is to run a message-passing benchmark on an idle system, then run it again with a CPU-bound process of equal priority in round-robin mode also running. If the message passing-task starves, or the CPU-bound task starves, message passing was misdesigned. If, on a multiprocessor, a simple message pass causes a CPU switch, message passing was done wrong.

If message passing and scheduling do not play very well together, a service-oriented architecture (sorry, "microservices" architecture) will be sluggish. This is where most microkernels fail.

[1] http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/i...

[scythe]

QNX is proprietary. Also, the NetBSD anykernel is where I think the sweetspot is.

[cpeterso]

Or MINIX. You could rewrite MINIX's microkernel servers one by one. You have a working kernel and userspace on day one and the end result is a robust microkernel design written in a safe language.