1. 60
  1.  

  2. 10

    So to be clear, this means that there will be Rust in the next-ish Linux kernel?

    That’s amazing. Linus has been loathe to put anything but C in there. This is an enormous step. How is that going to work for platforms where Linux is supported but not Rust? (I don’t know what the disjointedness of those sets are, maybe none.)

    1. 13

      From https://lwn.net/Articles/849849/:

      Appearance in linux-next generally implies readiness for the upcoming merge window, but it is not clear if that is the case here; this code has not seen a lot of wider review yet.

      Re: arch support: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/rust/arch-support.rst

      1. 1

        Yeah that’s going to limit what rust can be used for. At least at first.

        1. 1

          I think I saw in a mailing list somewhere that the plan was to “aim for” this merge window, but expect to miss it… with the idea that that would improve their odds of actually getting into the next merge window.

        2. 12

          It’s not clear from the title, but this is specifically support for writing device drivers in Rust.

          initial support for writing device drivers in the Rust language

          (from the same https://lwn.net/Articles/849849/)

          1. 8

            The GCC project is working on a Rust front end. That would presumably support Rust on any platform that Linux cares about. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/rust/arch-support.rst

            1. 2

              How is that going to work for platforms where Linux is supported but not Rust?

              For the foreseeable future, it remains possible to build the kernel without rust. That means rust support is limited to things like device drivers (this patch set) or I suppose architecture specific code.

            2. 4

              This is neat, though what would be more interesting to me (and what I’ve thus far been unable to find) is whatever discussion (of this particular code/merge) took place on the mailing list.

              From a quick skim it looks like the rust code is set up to panic on allocation failure in at least some scenarios – that’s certainly a thorny issue language-wise, but if it remains that way does that just relegate rust to second-class status, making it unable to implement a module capable of returning ENOMEM when appropriate? Have there been any breakthroughs on solving problems of interop with the rest of the kernel using very C-specific APIs like struct list_head or the tracepoint macros?

              Getting some basic code compilable and integrated into the build system is cool and an important step, but it still seems like there are much bigger and more difficult problems to address before there’s any clear path to it being viable for serious, widespread use in the Linux kernel.

              1. 6

                The panicking error handler is only for the alloc crate. If you allocate memory directly from the allocator, you can handle failures however you like. Rust is also adding fallible Box::try_new and Vec::try_reserve, so it should be possible to handle allocation errors gracefully even if you use the standard containers.

                And finally there’s catch_unwind to catch all panics. That will most likely be necessary anyway, just in case the code trips on something else like arr[bad_index].

                1. 1

                  I remember having to remove exception support and runtime support when developing a custom kernel module in c++, is that not the case with rust?

                  1. 1

                    Rust doesn’t have exceptions (panics are not an equivalent mechanism). However, you can choose to configure a crate to abort on panic instead of panicking the current thread and unwinding the stack, which removes the small bit of code necessary to support unwinding. In that case though, panics are no longer able to be handled, and instead kill the program entirely.

                    1. 1

                      Thanks, though I’m not sure how we can handle a panic during module initialization as resources need to be released in lifo order in case one of them fails. This might cause module initialization to hang and we won’t be able to unload.

              2. 4

                This is very exciting!