1. 16
  1.  

  2. 4

    No.

    A great deal of non trivial memory and state management is done in the kernel. A Rust code base that’s littered with countless unsafe blocks is not very safe at all. The standard library does not have allocator support, so using that’s out of the question. Panic is frequently used for cases that a kernel would need to handle, and unwinding is wholly unsuited for kernels.

    C was made for kernel development. Until a new language is created with the same raison d’etre, C isn’t going anywhere, and claiming that Rust or your favourite language is a suitable replacement is laughable.

    1. 17

      I do a fair bit of kernel work myself, and I think you are under selling the benefits of Rust even in a code base where some code must be unsafe like the core of an OS kernel. The benefits of the metaprogramming facilities for bit field manipulation alone are a huge boon for drivers, and the ease with which advanced collections and data structures can be used (without the allocator) is a breath of fresh air.

      Panic is frequently used for cases that a kernel would need to handle, and unwinding is wholly unsuited for kernels.

      I’m not sure what you mean by this. Especially if you’re not using the standard library, there are very few things that will just panic instead of return some Result or Option. Indeed, ensuring that return values are correctly handled is a mandatory part of serious C static analysis machinery in kernels today – Rust is semantically richer and such analysis is effectively in the language. I agree that unwinding is a no-go, and Rust provides excellent support for aborting/crashing on panic instead of unwinding – in an OS, you would hook this up to whatever usual panic() call you would make from C in the face of fatal logic errors.

      I think Rust is actually a fantastic language for kernel work, and embedded work, and I’m interested in incrementally using it for new UNIX development. I know others are too. Certainly I think the point being made in the video is that we will likely not rewrite everything as a specific goal, but that there are exciting opportunities for incrementally shifting toward a future where the lion’s share is Rust – as UNIX shifted from assembly to C five decades ago.

      1. 10

        I’m under the assumption that this is talking about libcollections, which panics on allocation failure.

        This is intentional - the stdlib wants to be broadly useful and most codebases do handle allocation failure by crashing.

        In this case, Rust makes it easy to ship collections with different behaviour, and those exist.

        For kernel work, you essentially want to use Rust with libcore + a number additional libraries behind the libstd facade. A simple example for this is the heapless crate, which does return a Result on push (not because of allocation failure, but because of missing space, but that’s conceptually similar).

        1. 2

          Ah yes, that makes sense. And I agree with your suggestions: those are the sorts of things we’ve been looking at in a couple of ongoing projects.

          I was thinking the other day that we could even accommodate some use of an allocator that doesn’t handle failure because we already have that with C today. If you call kmem_alloc(9F) with the KM_SLEEP flag, it will never return NULL. It might sleep for a long time, but it also puts memory pressure on the rest of the system to shrink other pools to make room, etc. Sometimes it’s the right approach to allocation, and I think would be broadly compatible with the expectations of at least parts of libstd.

          1. 2

            If you call kmem_alloc(9F) with the KM_SLEEP flag, it will never return NULL.

            There’s gotta be some upper limit though…what does it do if you try to allocate more memory than exists in the system? Block until somebody hotplugs in some additional DIMMs?

      2. 3

        Even if Rust made no memory safety guarantees whatsoever, the language is an improvement over C in many other ways (supporting ADTs, fixing a bunch of C syntactic footguns like braces after if statements, better external tooling, etc.) that I would rather write any kind of program in Rust than C. People are already writing OS kernels in Rust, and even though C was created in tandem with the Unix OS in the 1970s, it’s certainly not the only language anyone has ever written an operating system with.

        1. 3

          even though C was created in tandem with the Unix OS in the 1970s, it’s certainly not the only language anyone has ever written an operating system with.

          This raises the question: which operating systems? As far as I know, VMS, Windows NT and MacOS were or are written in C or a derivative of C.

          1. 2

            TempleOS! Inferno! :D

            1. 2

              Lisp machines for one, OS projects for the US army written in Ada for another. The original Mac OS (for the 1984 Apple Macintosh) was written in Pascal.

        Stories with similar links:

        1. Is It Time to Rewrite the Operating System in Rust? via catilac 1 year ago | 2 points | no comments