commit: 4e3e43e50224106b799fc3f12cd46494a5784ecc
parent 6d075a727b0748af0d8952ced9ebdf10713972b6
Author: Drew DeVault <sir@cmpwn.com>
Date: Mon, 3 Oct 2022 21:07:29 +0200
Rust in Linux
Diffstat:
1 file changed, 177 insertions(+), 0 deletions(-)
diff --git a/content/blog/Does-Rust-belong-in-Linux.md b/content/blog/Does-Rust-belong-in-Linux.md
@@ -0,0 +1,177 @@
+---
+title: Does Rust belong in the Linux kernel?
+date: 2022-10-03
+---
+
+I am known to be a bit of a polemic when it comes to Rust. I will be forthright
+with the fact that I don't particularly care for Rust, and that my public
+criticisms of it might set up many readers with a reluctance to endure yet
+another Rust Hot Take from my blog. My answer to the question posed in the title
+is, of course, "no". However, let me assuage some of your fears by answering
+a different question first: does Hare belong in the Linux kernel?
+
+If I should owe my allegiance to any programming language, it would be
+[Hare](https://harelang.org). Not only is it a systems programming language that
+I designed myself, but I am using it [to write a kernel][helios]. [Like
+Rust][redox], Hare is demonstrably useful for writing kernels with. One might
+even go so far as to suggest that I consider it superior to C for this purpose,
+given that I chose to to write Helios in Hare it rather than C, despite my
+extensive background in C. But the question remains: does Hare belong in the
+Linux kernel?
+
+[helios]: https://git.sr.ht/~sircmpwn/helios
+[redox]: https://www.redox-os.org/
+
+In my opinion, Hare does not belong in the Linux kernel, and neither does Rust.
+Some of the reasoning behind this answer is common to both, and some is unique
+to each, but I will be focusing on Rust today because Rust is the language which
+is actually making its way towards mainline Linux. I have no illusions about
+this blog post changing that, either: I simply find it an interesting case-study
+in software engineering decision-making in a major project, and that's worth
+talking about.
+
+Each change in software requires sufficient supporting rationale. What are the
+reasons to bring Rust into Linux? A kernel hacker thinks about these questions
+differently than a typical developer in userspace. One could espouse about
+Cargo, generics, whatever, but these concerns matter relatively little to kernel
+hackers. Kernels operate in a heavily constrained design space and a language
+has to fit into that design space. This is the first and foremost concern, and
+if it's awkward to mold a language to fit into these constraints then it will be
+a poor fit.
+
+Some common problems that a programming language designed for userspace will run
+into when being considered for kernelspace are:
+
+- Strict constraints on memory allocation
+- Strict constraints on stack usage
+- Strict constraints on recursion
+- No use of floating point arithmetic
+- Necessary evils, such as unsafe memory use patterns or integer overflow
+- The absence of a standard library, runtime, third-party libraries, or other
+ conveniences typically afforded to userspace
+
+Most languages can overcome these constraints with some work, but their
+suitability for kernel use is mainly defined by how well they adapt to them
+— there's a reason that kernels written in Go, C#, Java, Python, etc, are
+limited to being research curiosities and are left out of production systems.
+
+As Linus recently put it, "kernel needs trump any Rust needs". The kernel is
+simply not an environment which will bend to accommodate a language; it must go
+the other way around. These constraints have posed, and will continue to pose, a
+major challenge for Rust in Linux, but on the whole, I think that it will be
+able to rise to meet them, though perhaps not with as much grace as I would
+like.
+
+If Rust is able to work within these constraints, then it satisfies the ground
+rules for playing in ring 0. The question then becomes: what advantages can Rust
+bring to the kernel? Based on what I've seen, these essentially break down to
+two points:[^benefits]
+
+1. Memory safety
+2. Trendiness
+
+[^benefits]: There are some other arguable benefits which mainly boil down to
+ finding Rust to have a superior language design to C or to be more enjoyable
+ to use. These are subjective and generally are not the most important traits
+ a kernel hacker has to consider when choosing a language, so I'm leaving them
+ aside for now.
+
+I would prefer not to re-open the memory safety flamewar, so we will simply move
+forward with the (dubious) assumptions that memory safety is (1) unconditionally
+desirable, (2) compatible with the kernel's requirements, and (3) sufficiently
+provided for by Rust. I will offer this quote from an unnamed kernel hacker,
+though:
+
+> There are possibly some well-designed and written parts which have not
+> suffered a memory safety issue in many years. It's insulting to present this
+> as an improvement over what was achieved by those doing all this hard work.
+
+Regarding "trendiness", I admit that this is a somewhat unforgiving turn of
+phrase. In this respect I refer to the goal of expanding the kernel's developer
+base from a bunch of aging curmudgeons writing C[^ageism] towards a more
+inclusive developer pool from a younger up-and-coming language community like
+Rust. C is boring[^boring] — it hasn't really excited anyone in decades.
+Rust is exciting, and its community enjoys a huge pool of developers building
+their brave new world with it. Introducing Rust to the kernel will certainly
+appeal to a broader audience of potential contributors.
+
+[^boring]: A trait which, I will briefly note, is actually desirable for a
+ production kernel implementation.
+
+[^ageism]: A portrayal which, though it may have a grain of truth, is largely false
+ and offensive to my sensibilities as a 29-year-old kernel hacker. For the
+ record.
+
+But there is an underlying assumption to this argument which is worth
+questioning: is the supply of Linux developers dwindling, and, if so, is it to
+such and extent that it demands radical change?
+
+Well, no. Linux has consistently enjoyed a tremendous amount of attention from
+the software development community. This week's release of Linux 6.0, one of the
+largest Linux releases ever, boasted more than 78,000 commits by almost 5,000
+different authors since 5.15. Linux has a broad developer base reaching from
+many different industry stakeholders and independent contributors working on the
+careful development and maintenance of its hundreds of subsystems. The scale of
+Linux development is on a level unmatched by any other software project —
+free software or otherwise.
+
+Getting Rust working in Linux is certainly an exciting project, and I'm all for
+developers having fun. However, it's not likely to infuse Linux with a
+much-needed boost in its contributor base, because Linux has no such need.
+What's more, Linux's portability requirements prevent Rust from being used in
+most of the kernel in the first place. Most work on Rust in Linux is simply
+working on getting the systems to cooperate with each other or writing drivers
+which are redundant with existing C drivers, but cannot replace them due to
+Rust's limited selection of targets.[^gcc] Few to none of the efforts from the
+Rust-in-Linux team are likely to support the kernel's broader goals for some
+time.
+
+[^gcc]: Rust in GCC will help with this problem, but it will likely take several
+ years to materialize and several more years to become stable. Even when this
+ is addressed, rewriting drivers wholesale will be labor intensive and is
+ likely to introduce more problems than solutions — rewrites always
+ introduce bugs.
+
+We are thus left with memory safety as the main benefit offered by Rust to
+Linux, and for the purpose of this article we're going to take it at face value.
+So, with the ground rules set and the advantages enumerated, what are some of
+the problems that Rust might face in Linux?
+
+There are a few problems which could be argued over, such as substantial
+complexity of Rust compared to C, the inevitable doubling of Linux's build time,
+the significant shift in design sensibilities required to support an idiomatic
+Rust design, the fragile interface which will develop on the boundaries between
+Rust and C code, or the challenges the kernel's established base of C developers
+will endure when learning and adapting to a new language. To avoid letting this
+post become too subjective or lengthy, I'll refrain from expanding on these.
+Instead, allow me to simply illuminate these issues as risk factors.
+
+Linux is, on the whole, a conservative project. It is deployed worldwide in
+billions of devices and its reliability is depended on by a majority of Earth's
+population. Risks are carefully evaluated in Linux as such. Every change
+presents risks and offers advantages, which must be weighed against each other
+to justify the change. Rust is one of the riskiest bets Linux has ever
+considered, and, in my opinion, the advantages may not weigh up. I think that
+the main reason we're going to see Rust in the kernel is not due to a careful
+balancing of risk and reward, but because the Rust community wants Rust in
+Linux, and they're large and loud enough to not be worth the cost of arguing
+with.
+
+I don't think that changes on this scale are appropriate for most projects. I
+prefer to encourage people to write new software to replace established
+software, rather than rewriting the established software. Some projects, such as
+[Redox][redox], are doing just that with Rust. However, operating systems are in
+a difficult spot in this respect. Writing an operating system is difficult work
+with a huge scope — few projects can hope to challenge Linux on driver
+support, for example. The major players have been entrenched for decades, and
+any project seeking to displace them will have decades of hard work ahead of
+them and will require a considerable amount of luck to succeed. Though I think
+that new innovations in kernels are badly overdue, I must acknowledge the that
+there is some truth to the argument that we're stuck with Linux. In this
+framing, if you want Rust to succeed in a kernel, getting it into Linux is the
+best strategy.
+
+But, on the whole, my opinion is that the benefits of Rust in Linux are
+negligible and the costs are not. That said, it's going to happen, and the
+impact to me is likely to be, at worst, a nuisance. Though I would have chosen
+differently, I wish them the best of luck and hope to see them succeed.
