5 ms·

So there is this, and there is also http://www.redox-os.org http://www.redox-os.org. Are there any other OS' being built in Rust? I'm curious about the intenti

So there is this, and there is also http://www.redox-os.org http://www.redox-os.org. Are there any other OS' being built in Rust? I'm curious about the intention of these two projects, this seems to be a bottom up OS in Rust probably oriented toward unikernel or possibly a server OS. To be successful I assume it's going to allow for NetBSD or Linux drivers to be integrated into the Kernel in some way?

cmrx64 11y ago
Me and some other people are working on a seL4-based OS in Rust. We're getting ready to publically announce our first milestone by next week. There's also https://github.com/thepowersgang/rust_os https://github.com/thepowersgang/rust_os, which is one of the oldest OS written in Rust, but never gets any press.
- bluejekyll 11y ago
  Sweet! I love the L4 design.
- phil-opp 11y ago
  Yeah, thepowersgang's kernel is severely underrated.
valarauca1 11y ago
/u/steveklabnik1 is writing one https://intermezzos.github.io/ https://intermezzos.github.io/
drzaiusapelord 11y ago
> I assume it's going to allow for NetBSD or Linux drivers to be integrated into the Kernel in some way? How is that possible? An intermediate layer? The kernel is going to be written in rust. You can't just put C code in there and expect it to work. I'm not even sure how you could transcode these drivers into rust considering rust uses a completely different memory model. I suspect a 'real' RustOS will require new drivers to be written from scratch. From a mass adoption perspective, how would have linux worked out if Linus decided to write windows driver shims? I wonder if its feasible to rewrite things like apache, nginx, php, mysql, gnu utils, etc in Rust but keep the linux kernel as-is. Seems like you'd get the best of both worlds there - a mature and powerful kernel and a Rust userland that's hard to exploit. Most exploited vulnerabilities and stability issues aren't kernel related anyway. Mozilla's servo project is also interesting. Maybe I don't need a RustOS (yet), but just my internet facing applications in Rust.
- polyfractal 11y ago
  You can do what Rump kernels do: write a shim layer. The linux/netbsd drivers think they are talking to their host kernel, when in reality they are talking to a shim that translates linux syscalls into the equivalent "RustOS" syscalls. Or you could just implement the linux syscalls directly in the kernel, but that seems a bit self-defeating if you want to explore new ideas.
  - drzaiusapelord 11y ago
    Is this feasible for a production server or just POC? Its worrying to think of a layer between the OS and its video driver, raid controller driver, sound driver, network driver, etc. Any real decrease in performance or stability will be a non-starter for most.
    - polyfractal 11y ago
      Well, that's how all the NetBSD rump drivers work. IIUC, a while back they refactored all the drivers to interact with the NetBSD kernel through the Rump interface. Which means that all the drivers can work in a traditional monolithic kernel, or can be extracted and used piecemeal in your own kernel, or compiled directly into the application as a unikernel. Checkout http://rumpkernel.org/ http://rumpkernel.org/ for more info. I dunno about performance impact, but I bet it is fairly negligible in the grand scheme of things. In the rump kernel case, these shims really don't do anything, they just pass the call through. Think of it as an API facade. In a hobby OS it might be heavier, if your OS doesn't have a 1:1 mapping of the POSIX/linux syscall to an equivalent. Also, we virtualize this stuff all the time in cloud environments. Your java app uses the JVM to execute a linux syscall which the kernel translates into a Xen hypercall which Xen uses to call a native driver which talks to the disk, etc etc. You obviously do pay a performance penalty for stacking more and more layers, but it isn't as bad as you'd think (or as good as you hope, take your pick). But the point is that layering abstractions like this is very much alive and tolerated today in moderately high performance systems :)
  - bluejekyll 11y ago

cmrx64 11y ago

Me and some other people are working on a seL4-based OS in Rust. We're getting ready to publically announce our first milestone by next week. There's also https://github.com/thepowersgang/rust_os https://github.com/thepowersgang/rust_os, which is one of the oldest OS written in Rust, but never gets any press.

bluejekyll 11y ago
Sweet! I love the L4 design.
phil-opp 11y ago
Yeah, thepowersgang's kernel is severely underrated.

valarauca1 11y ago

/u/steveklabnik1 is writing one https://intermezzos.github.io/ https://intermezzos.github.io/

drzaiusapelord 11y ago

> I assume it's going to allow for NetBSD or Linux drivers to be integrated into the Kernel in some way? How is that possible? An intermediate layer? The kernel is going to be written in rust. You can't just put C code in there and expect it to work. I'm not even sure how you could transcode these drivers into rust considering rust uses a completely different memory model. I suspect a 'real' RustOS will require new drivers to be written from scratch. From a mass adoption perspective, how would have linux worked out if Linus decided to write windows driver shims? I wonder if its feasible to rewrite things like apache, nginx, php, mysql, gnu utils, etc in Rust but keep the linux kernel as-is. Seems like you'd get the best of both worlds there - a mature and powerful kernel and a Rust userland that's hard to exploit. Most exploited vulnerabilities and stability issues aren't kernel related anyway. Mozilla's servo project is also interesting. Maybe I don't need a RustOS (yet), but just my internet facing applications in Rust.

polyfractal 11y ago
You can do what Rump kernels do: write a shim layer. The linux/netbsd drivers think they are talking to their host kernel, when in reality they are talking to a shim that translates linux syscalls into the equivalent "RustOS" syscalls. Or you could just implement the linux syscalls directly in the kernel, but that seems a bit self-defeating if you want to explore new ideas.
- drzaiusapelord 11y ago
  Is this feasible for a production server or just POC? Its worrying to think of a layer between the OS and its video driver, raid controller driver, sound driver, network driver, etc. Any real decrease in performance or stability will be a non-starter for most.
  - polyfractal 11y ago
    Well, that's how all the NetBSD rump drivers work. IIUC, a while back they refactored all the drivers to interact with the NetBSD kernel through the Rump interface. Which means that all the drivers can work in a traditional monolithic kernel, or can be extracted and used piecemeal in your own kernel, or compiled directly into the application as a unikernel. Checkout http://rumpkernel.org/ http://rumpkernel.org/ for more info. I dunno about performance impact, but I bet it is fairly negligible in the grand scheme of things. In the rump kernel case, these shims really don't do anything, they just pass the call through. Think of it as an API facade. In a hobby OS it might be heavier, if your OS doesn't have a 1:1 mapping of the POSIX/linux syscall to an equivalent. Also, we virtualize this stuff all the time in cloud environments. Your java app uses the JVM to execute a linux syscall which the kernel translates into a Xen hypercall which Xen uses to call a native driver which talks to the disk, etc etc. You obviously do pay a performance penalty for stacking more and more layers, but it isn't as bad as you'd think (or as good as you hope, take your pick). But the point is that layering abstractions like this is very much alive and tolerated today in moderately high performance systems :)
- bluejekyll 11y ago