1. 63
  1.  

  2. 8

    When more and more Rust seeps into the kernel, we might end up with the situation that the kernel takes longer to compile than Chromium.

    1. 17

      Not if Chromium itself doesn’t stand still!

      https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rust-toolchain.md

      I would also expect the kernel to stick with fast-to-compile C-style subset of Rust, which is probably still quite a bit slower than C, but should be significantly faster than the typical monomorphisation-heavy userspace Rust code.

    2. 3

      …things have begun settling down in the initial Rust enablement code for the kernel with the basic infrastructure, a few basic sample drivers, etc.

      What’s most interesting and exciting to me here are the dual opportunities of:

      1. “Safely” rewriting core kernel components.
      2. The chance to build net-new functionality in Rust.

      As noted plenty of times before, this Rust support within the Linux kernel will remain optional when building the kernel depending upon whether you want the support or any of the kernel features to be implemented just in Rust code.

      Based on point 1 above, how long will the optionality endure?

      1. 10

        Based on point 1 above, how long will the optionality endure?

        Presumably for quite some time yet. At this stage, all that’s being added is a shim to allow writing drivers in idiomatic Rust. Moving beyond drivers would likely require Rust to start supporting architectures the kernel explicitly supports which Rust/LLVM does not as of yet. Nothing beyond drivers is currently being discussed.

        1. 8

          Uninformed opinion:

          • until core functionality requires rust, which in turn means
          • rustc runs on all required architectures or
          • gcc backend supports rust (in the making), enabling compilation for all architectures the linux kernel requires

          And also it’s still room to explore how much rust will be written for the kernel and how well that plays out.

        2. 1

          What effect will this have on Rust development (Syntax and idioms)? Does this mean that the syntax of the Rust version that gets merged into the Kernel will be more blessed? (i.e., when newer syntax/idioms are invented by the community at a later time?)

          1. 3

            Linux is likely to influence some small features. They have opinions about panicking, OOM handling. Rust will very likely get a feature to disable floating-point support for Linux.

            However, I don’t expect this to make a noticably different “kernel Rust” language. Rust already has a “no_std” flavor that is used for other OSes and embedded development.

          2. 1

            It’s nice to see more safety in the Linux kernel but I worry about Linux following the BSDs in dropping support for older platforms that don’t have the corporate backing for a high quality LLVM port.

            1. 6

              Writing an LLVM back end is usually a lot easier than writing a GCC back end, so if a platform has enough community support to maintain a GCC back end then it should be able to handle maintaining an LLVM one. We’re seeing that at the moment with m68k, where the hobbyist community is able to fund development of an LLVM m68k back end that’s en route to upstreaming. If an community for a niche architecture can’t generate enough interest to contribute an LLVM back end (or maintain one out of tree) then it’s unlikely to be tested well enough by the rest of the stack for things to work reliably.

              1. 5

                To be fair there are quite a few architectures that have better support on NetBSD and/or OpenBSD than especially unpatched Linux.

                Many years ago I was fooling around with some of them. Parisc for example. Debian simply didn’t work, some others also didn’t despite claiming to support it, Gentoo managed to run.. somewhat. OpenBSD worked.

                Similar situation on super exotic systems like Dreamcast which only every booted NetBSD.

                While Linux in theory supports various old systems in reality third party patches on outdated kernel versions are needed and then you only have a kennel. Userland tends to be even worse.

                In Linux land you notice a lot more whether a developer recently came across it.

                FreeBSD dropping support for architectures seems to mostly be about making that state official and while I would assume that Linux itself has better support for things like Sun’s architectures or Itaniums still I really wonder how much that goes above a theoretical level when “nobody” actually does so and maintain it.

                With such architectures you are really dependent on the mood and time of individual people.

                NetBSD for a while had big pride in portability so people actually made sure stuff works. I mean they do similar things with pkgsrc which are or were the official package manager for Minix, some Open Solaris/Illumos distros, Linux distros, DragonFly and worked on many other systems.

                So llvm, clang and Rust are certainly not where gcc is, but I’d argue that this is changing both in the theoretical and practical.

                But I agree the initial commercial banking is something that llvm misses on older platforms. But I also think that Rust in the kennel would suddenly completely replace C with no alternatives available.

                1. 1

                  This has been a long-running problem with GCC, too.