4 ms·

I'm normally quite happy to advocate for Rust everywhere, but one of the benefits of the microkernel architecture is that you have a very small trusted computin

I'm normally quite happy to advocate for Rust everywhere, but one of the benefits of the microkernel architecture is that you have a very small trusted computing base for your system. Yes, Rust could help, but there are lots of techniques for building highly reliable C/C++ codebases, and one of the main reasons they don't get used more in large codebases is that they don't scale super well. But, in a microkernel it's much easier to apply those methods. See for example the sel4 microkernel, which is small enough to have a well-verified model for a bunch of different hardware. Uh, this is rambling a bit. My point is that building zircon as a microkernel makes it much easier to write correct code, Rust or not. And that maybe the overhead of a rewrite wouldn't be as beneficial for the microkernel as it would be for other parts of the operating system.

colemickens 9y ago
This is virtually the same reply that every single "rust would help with safety" comment gets every time without fail. And despite those tools, mistakes occur in the most critical of codebases. In fact just early today a patch to LKML was being mocked because some pointer manipulation in C was clearly buggy and uncaught due to the lack of safety and sophistication of the type system.
- dikaiosune 9y ago
  I don't think this is quite the template reply (and if you check my HN comment history, I think you might see that I'm quite familiar with receiving the template replies!), what I meant to say is that it'd be much higher leverage to rewrite other parts of Fuchsia in Rust than to rewrite Zircon.
  - colemickens 9y ago
    Sorry, I didn't mean to put words in your mouth or anything. I am quite curious which parts you think would better benefit from a rewrite in a safer language if you might elaborate. Thanks!
    - dikaiosune 9y ago
      Oh no worries, I might have come off a bit defensive there. I think one of the clearest examples would be drivers -- they might be properly sandboxed by a good microkernel, but they are notoriously buggy/crashy/incorrect. If I remember correctly one of the Fuchsia team members told me that they were going to support drivers written in Rust, but I could be completely wrong. Filesystems, the network stack, whatever horrifying systemd equivalent Fuchsia grows, etc. are all examples of things I would advocate for writing in Rust before focusing on the kernel. All of these things are still security/reliability sensitive, all still terrible by Rustacean safety standards in most OSes, and conveniently don't have to be built directly as part of the kernel when you're doing a microkernel. Just spitballing, of course.
      - pjmlp 9y ago
        Some filesystems and the network stack from Fuchsia are written in Go.
        dikaiosune 9y ago
        Cool! Accomplishes many of the same goals that doing it in Rust would, arguably. I would be curious to hear about what sort of latency-management techniques they've used to build an FS in a GC'd environment.
        pjmlp 9y ago
        Here is some more information https://github.com/fuchsia-mirror?language=go https://github.com/fuchsia-mirror?language=go https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1PgTXAwAJ https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1P... Regarding your specific latency issue with a GC systems language, here is a Mesa/Cedar example about a network file server. http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-6.pdf http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-6.pdf
indolering 9y ago
> See for example the sel4 microkernel, which is small enough to have a well-verified model for a bunch of different hardware. The workflow for seL4 starts with prototyping in Haskell, formalizing everything in Isabelle, and then translating into C. This results in highly unusual C code and much of it would be better serviced with a DSL. I'm guessing that C chosen because it has formally verified semantics and compilers as well as integration with proofing assistants.

colemickens 9y ago

This is virtually the same reply that every single "rust would help with safety" comment gets every time without fail. And despite those tools, mistakes occur in the most critical of codebases. In fact just early today a patch to LKML was being mocked because some pointer manipulation in C was clearly buggy and uncaught due to the lack of safety and sophistication of the type system.

dikaiosune 9y ago
I don't think this is quite the template reply (and if you check my HN comment history, I think you might see that I'm quite familiar with receiving the template replies!), what I meant to say is that it'd be much higher leverage to rewrite other parts of Fuchsia in Rust than to rewrite Zircon.
- colemickens 9y ago
  Sorry, I didn't mean to put words in your mouth or anything. I am quite curious which parts you think would better benefit from a rewrite in a safer language if you might elaborate. Thanks!
  - dikaiosune 9y ago
    Oh no worries, I might have come off a bit defensive there. I think one of the clearest examples would be drivers -- they might be properly sandboxed by a good microkernel, but they are notoriously buggy/crashy/incorrect. If I remember correctly one of the Fuchsia team members told me that they were going to support drivers written in Rust, but I could be completely wrong. Filesystems, the network stack, whatever horrifying systemd equivalent Fuchsia grows, etc. are all examples of things I would advocate for writing in Rust before focusing on the kernel. All of these things are still security/reliability sensitive, all still terrible by Rustacean safety standards in most OSes, and conveniently don't have to be built directly as part of the kernel when you're doing a microkernel. Just spitballing, of course.
    - pjmlp 9y ago
      Some filesystems and the network stack from Fuchsia are written in Go.
      - dikaiosune 9y ago
        Cool! Accomplishes many of the same goals that doing it in Rust would, arguably. I would be curious to hear about what sort of latency-management techniques they've used to build an FS in a GC'd environment.
        pjmlp 9y ago
        Here is some more information https://github.com/fuchsia-mirror?language=go https://github.com/fuchsia-mirror?language=go https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1PgTXAwAJ https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1P... Regarding your specific latency issue with a GC systems language, here is a Mesa/Cedar example about a network file server. http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-6.pdf http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-6.pdf

indolering 9y ago

> See for example the sel4 microkernel, which is small enough to have a well-verified model for a bunch of different hardware. The workflow for seL4 starts with prototyping in Haskell, formalizing everything in Isabelle, and then translating into C. This results in highly unusual C code and much of it would be better serviced with a DSL. I'm guessing that C chosen because it has formally verified semantics and compilers as well as integration with proofing assistants.