LWN: Comments on "The Rust for Linux project"

The Rust for Linux project

neilbrown — Sat, 02 Oct 2021 21:40:37 +0000

> In any busy project, maintainers tend to operate at 100+% of their capacity.

Then they need to delegate. Or abdicate.
Such behaviour is not good for the mental health of the maintainer or the long term health of the project. Just don't do it.
If you stop, that creates a vacuum. Vacuums tend to get filled.

The Rust for Linux project

bfields — Fri, 01 Oct 2021 20:27:50 +0000

In any busy project, maintainers tend to operate at 100+% of their capacity. Whenever they need to learn something new, that effort is taken away from their "usual" activities (which are possibly the activities that they get paid for).

Compared to the stuff I'm usually fighting to swap in (how does the dcache work again?), I feel like a new language isn't too bad. They're well-documented. They usually share a lot with other languages. The basics you need to get started usually just aren't that complicated.

The Rust for Linux project

Wol — Wed, 29 Sep 2021 11:22:16 +0000

As someone who's currently being paid to "learn something new", it's painful!

I'm now working with Oracle rather than Pick, so switching from ENGLISH to SQL is horrible. SQL is just so much more convoluted, slow, horrendous ... (and I've just managed to speed up a query from 10 mins to 2, just by thinking hard about how it was written. The Pick version would probably have taken one minute as the first draft!).

Then there's learning VBA. Okay, I know assorted programming languages so this isn't so bad ...

But it gets wearing when pretty much everything you want to do results in a google query for "what's the syntax for doing XYZ?". And working remotely, I can't even easily ask my co-workers ...

Cheers,
Wol

The Rust for Linux project

lacos — Wed, 29 Sep 2021 10:20:46 +0000

> Is it a principle of Linux development that "kernel maintainers shall not be required to learn anything new"?

In any busy project, maintainers tend to operate at 100+% of their capacity. Whenever they need to learn something new, that effort is taken away from their "usual" activities (which are possibly the activities that they get paid for). Obviously they keep learning new things incrementally, but new material that's intrusive and has a steep learning curve (= late RoI) must be a different sell.

> I guess the problem is that those changes have been incremental but "learn Rust" is not.

IMO: exactly so.

The Rust for Linux project

mathstuf — Mon, 27 Sep 2021 13:06:52 +0000

My gut feeling is that it is more around figuring out what the optimizer can help out with. Rust can probably optimize iterator method chains far better than C's loops, but at that point, you're also fiddling with details that affect the inline heuristic engine and other such details that vary between compiler implementations and versions of the same compiler, so even there I'd think that "what my specific compiler does" may not be suitable because the optimization could fall on the other side of the line in the next release too.

The Rust for Linux project

marcH — Sun, 26 Sep 2021 08:08:25 +0000

For small and trivial pieces of C maybe (I wrote "non-trivial"). Are the equivalent parts in Rust harder to predict and if so why? Interesting question.

The Rust for Linux project

error27 — Fri, 24 Sep 2021 14:37:48 +0000

People might surprise you.

Some of the kernel is written in assembly. But there are definitely parts which are written in C but the author has the assembly in mind and reviews the assembly to verify.

The Rust for Linux project

marcH — Thu, 23 Sep 2021 04:54:13 +0000

> For me, screwing up a review in C results in bugs, screwing up a review in Rust results in technical debt, and sometimes I'm not sure which one is worse.

Define "worse", on which axis?

Debugging undefined behaviors and race conditions or refactoring existing code? I have my preference...

The Rust for Linux project

marcH — Thu, 23 Sep 2021 04:15:53 +0000

> It's somewhat low-level like C but, depending on the code, it might be less easy for developers to predict what the resulting assembly code will look like.

I really doubt anyone can predict the assembly code produced from any non-trivial piece of C unless they turn off optimizations.

https://queue.acm.org/detail.cfm?id=3212479 "C is not a low-level language", etc.

The Rust for Linux project

marcH — Thu, 23 Sep 2021 04:11:03 +0000

I think the question is: are they worth repeating?

Architecture support

flussence — Tue, 21 Sep 2021 06:00:23 +0000

I predict that the world won't suddenly end once it's in... and the ones complaining loudest will probably go on for some time as if it still wasn't.

Most old/exotic platforms aren't plug-and-play anyway; even if every new peripheral and PCIe card going forward had a pure-Rust driver it's unlikely to affect anyone on m68k, mips, alpha etc.

(The kernel's already got plenty of platform-limited compiler-dependent stuff anyway: LLVM LTO and GCC hardening plugins come to mind - those two are even mutually exclusive!)

The Rust for Linux project

moltonel — Mon, 20 Sep 2021 15:17:13 +0000

> For me, screwing up a review in C results in bugs, screwing up a review in Rust results in technical debt

I understand the fear, but it doesn't match my experience.

First the most obvious: paying technical debt (aka refactoring) is easier in Rust, because an API change will be noticed by the compiler in all callers, whereas in C many would be wrongly ignored. I rarely get the "needs a refactor but I'm too afraid to break things so I'll leave it" feeling with Rust.

Second, Rust helps making APIs that are harder to misuse, actively fighting technical debt. That's what you encountered when you realized you needed to throw away your first version(s). You probably should throw away your first C version too, but the compiler and base APIs don't tell you that. In a way, rustc is your first reviewer, making the human reviewer's job simpler. It might cause some anger when you're still learning that API or Rust itself, but it seems worth it.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

broonie — Sat, 18 Sep 2021 18:32:53 +0000

Right, and especially drivers needing some new subsystem improvements to cope with some new feature or usage pattern that the hardware has - this is especially true for things not on standardised buses (or not entirely) where it’s much easier for hardware to do new things.

The Rust for Linux project

federico3 — Sat, 18 Sep 2021 11:22:49 +0000

It does not. Nim would have been a better choice.

The Rust for Linux project

laarmen — Sat, 18 Sep 2021 09:00:17 +0000

IMO this comes mostly from the fact that the bindings expose in a formal way some assumptions that are only informally known in the C codebase. I agree those are *really* painful to read and review (as they are to write...).

However, I often find pure Rust code patches easier to review than pure C patches, assuming knowledge of the underlying code base, as Rust allows for stronger local reasoning. If the patch introduces a call looking like foo(&my_struct), Rust tells me that the contents of my_struct won't change (barring interior mutability) whereas, seeing the exact same call in C, I'll need to know the particulars of foo() in order to judge the soundness of further use of my_struct.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

matthias — Sat, 18 Sep 2021 08:24:26 +0000

It is not the driver requiring changes to the subsystems that gray wolf and broonie are talking about, but the other direction. I.e., a change to the subsystem that requires all users to be adapted. In this case the maintainer of the subsystem has to adapt the rust wrapper for the C API.

The Rust for Linux project

pbonzini — Sat, 18 Sep 2021 03:52:44 +0000

I tihnk this might apply more when Rust is brought into well-established codebases, that already have a certain complexity (both essential and accidental) baked in. Idiomatic Rust bindings pile more complexity on top.

The Rust for Linux project

roc — Sat, 18 Sep 2021 00:06:42 +0000

TBH I find this considerably worse in C++, because there are a lot more possible ways to do things in C++.

Seems to me your concern applies mainly to green-field development in Rust. Actual *maintenance* presents these questions less often, and when it does the solutions will be constrained by the patterns already set up.

But it would be interesting to collect more specific examples and see what can be done to provide guidance. I personally don't feel this burden myself. Maybe it's because I've been writing Rust code for five years, but even when I look at the code I wrote in the first year I think the design generally holds up.

The Rust for Linux project

st33med — Fri, 17 Sep 2021 23:39:38 +0000

It took me a bit to realize what you were getting at with 'technical debt' but I think I get it. If I understand you correctly, you're worried that the increased features adds to the complexity and thus costs later on to develop on top of a Rust library or rewrite it.

In C, I would argue many things are presented as 'overly simplified' with hidden behaviors that many developers may not consider until it bites you with undefined behavior. The typing system is not very strict which gives many footguns, there's practically no such thing as memory safety, etc. I think you know all this, and you're right that Rust adds features to be safe, and programming under Rust with this subset takes some time to think about how you want a program to function.

What I'm getting at is that it takes time and experience with Rust to be able to formulate an effective and friendly program structure, just like many other programming languages. You wouldn't be expected to pick up Haskell and know exactly the 'right' way to make a web server application, and Rust is no different. There's also never one obvious way to construct a program; sometimes you do need to scrap your current code and start over, regardless of the language used, and that happens less as you learn about the tools you are using.

The additional features of Rust do add more to consider in your design and may add to technical debt later on, but with experience, you gain insight into how your program synergizes with the Rust model and it becomes less of a burden. Likewise, the clearly marked unsafe portions of code, enforced typing model, and lack of undefined behavior remove a lot of time reviewing code and running static checkers against your program, of which C++ does not really remove despite being more 'feature-rich' than C and containing things like templates that Rust doesn't have.

Recordings

ojeda — Fri, 17 Sep 2021 19:32:55 +0000

(For the other talks, I recommend attending the "Rust Monday" at LPC -- some of the content will be similar).

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

ojeda — Fri, 17 Sep 2021 19:00:46 +0000

> These are really obvious questions, so I've likely just overlooked it already being discussed somewhere.

No, I don't think you overlooked :) We have talked about these points a few times, but they are still quite open. At LPC next week we will try to have this discussion with more kernel maintainers.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

ojeda — Fri, 17 Sep 2021 16:58:15 +0000

> No, they don't. At the moment, the Rust side is a client of the C APIs, and thus the modifications to the C side are minimal.

Ignore this sentence -- I thought you were referring to the Rust changes. For kernel changes in general, yes, some of them change different places in the kernel (the second part of the comment addresses that).

The Rust for Linux project

pbonzini — Fri, 17 Sep 2021 16:42:47 +0000

It's not about the correctness, it's the complexity. For me reviewing Rust means constantly asking myself "is this the right way to do it, or will it become excessive complexity and technical debt in the future". For me, screwing up a review in C results in bugs, screwing up a review in Rust results in technical debt, and sometimes I'm not sure which one is worse.

Almost every time I wrote complex code in Rust, I ended up throwing away the first version because I went down the wrong way to define types, establish ownership policies, pick what was hardcoded vs. what was abstracted. And it took a while to realize that, possibly only after using the library in anger. That is what I found even worse in Rust than in C++.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

ojeda — Fri, 17 Sep 2021 16:41:33 +0000

> my understanding is that lot (some?) of the changes require some modifications even in other subsystem

No, they don't. At the moment, the Rust side is a client of the C APIs, and thus the modifications to the C side are minimal.

The problem is that, even in this case, if you are doing subsystem or tree-wide changes that change C APIs, and they happen to be used by Rust code, then you would also need to update those.

This is what some kernel maintainers/developers that regularly do those kind of changes are worried about -- they would need to learn Rust fairly soon, which may put a big burden on them. Thus we may need to have a way to smooth things for them (e.g. relaxing the rules, helping them write or review the Rust side of the code, etc.).

The Rust for Linux project

moltonel — Fri, 17 Sep 2021 16:16:58 +0000

Rust does take time to become proficient in (though less than C++, and even C depending on how high you place the "proficient" bar), but Rust is "a language where you get the hangover first" and the giddy state afterwards. To me, reviewing Rust incurs a lower mental overhead thanks to the lack of UB and the much more informative type system.

Recordings

ojeda — Fri, 17 Sep 2021 16:06:46 +0000

Indeed, we will post the invited talks (probably after LPC).

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

pbonzini — Fri, 17 Sep 2021 15:56:01 +0000

I understand, the simplest case being a SCSI adapter sitting on a PCI bus. Such a driver obviously would need Rust bindings to both subsystems. But it's rare for drivers to "require some modifications even in other subsystems" (quoting the message I replied to). Usually driver changes are fairly self-contained.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

broonie — Fri, 17 Sep 2021 15:21:19 +0000

You'd be surprised how many drivers interact with multiple subsystems - for example it's very common to consume multiple APIs for resources like control bus, clocks, regulators and GPIOs while also offering another API to their own users. The whole thing about drivers not needing to interact with much is very much an assumption based on server type systems.

Recordings

corbet — Fri, 17 Sep 2021 13:26:25 +0000

My understanding is that recordings for a subset of the talks will be posted.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

pbonzini — Fri, 17 Sep 2021 09:47:21 +0000

There are some subsystems which are very central and would be "forcibly" made part of the Rust effort, because their API would have Rust-to-C bindings. Changing APIs in those subsystems would require changes to the bindings. This is for example the case for VFS, where Rust drivers may have to define file_operations (hence my question to Miguel, that the article refers to).

But apart from that, for something such as drivers (which are the initial focus of the project), the cases of patches affecting multiple subsystems are quite rare.

The Rust for Linux project

pbonzini — Fri, 17 Sep 2021 09:42:46 +0000

I think the problem is the magnitude of the change. Being proficient in Rust is not an easy skill to achieve.

As a maintainer (not as a kernel maintainer), my main worry in adopting Rust is: will I be able to review code effectively? will I correctly identify neverending sources of future technical debt and stop them from entering the project?

I like the language, but despite the extra safety guarantees offered by the compiler, I find Rust code to be very hard to review, even more so than C++.

How will cooperation of rust-knowing and not-rust-knowing maintainers look like?

gray_-_wolf — Fri, 17 Sep 2021 09:28:36 +0000

Hm, I still don't understand how the "at first work only with subsystems/maintainers that are interested" is supposed to work. Admittedly, I do not know much about linux development, but from the articles and comments on this site my understanding is that lot (some?) of the changes require some modifications even in other subsystems, even if your main patch is focused on one.

If the other subsystem is (partially) in rust, which you do not know, how would that be handled? If some parts of your patch touch some rust code, but goes via a tree of a maintainers that does not know rust, how should that be handled?

Just to make it clear, I really am just trying to understand how this will (would?) work. These are really obvious questions, so I've likely just overlooked it already being discussed somewhere.

The Rust for Linux project

beagnach — Fri, 17 Sep 2021 07:40:01 +0000

This is a challenging, multi-year project. I think we can reasonably expect the talking points to remain much the same for months at a time.

The Rust for Linux project

kaviraj — Fri, 17 Sep 2021 06:45:17 +0000

Is the conference recordings available for public? Couldn’t find it in the website https://kangrejos.com/

The Rust for Linux project

atnot — Fri, 17 Sep 2021 02:27:38 +0000

To be clear, I'm very much in favor of rust in the kernel, I just felt a strong deja vu from the discussion. It sounds like that was perhaps just some deliberate retreading of ground for the first day though, I haven't watched the others yet.

The Rust for Linux project

roc — Thu, 16 Sep 2021 23:47:52 +0000

Is it a principle of Linux development that "kernel maintainers shall not be required to learn anything new"? Presumably over time kernel devs have had to learn new rules for writing C code, as the kernel C dialect has moved away from standard C and issues like memory ordering have become important. I guess the problem is that those changes have been incremental but "learn Rust" is not. That's certainly a valid issue.

Architecture support

Wol — Thu, 16 Sep 2021 22:39:57 +0000

Whoops, sorry Jon, I know you know that, but this seems to be a negative meme that too many people jump on.

Cheers,
Wol

Architecture support

Wol — Thu, 16 Sep 2021 22:38:27 +0000

Does it NEED to work on all the platforms?

If they start off writing code that will only be run on supported platforms, it doesn't need to run on the others.

If there's a "rust to C" translator (I believe there is), then they can use that for unsupported platforms.

And as rust gains a foothold, it will provide pressure for the list of supported platforms to grow.

These things don't burst on the scene fully-fledged - linux didn't, why should rust?

What's that saying? If you don't evolve you die? Maybe rust is the next evolution for linux? Maybe it isn't, but don't put artificial obstacles in the way - you should know linux well enough to know it will evolve around and past you if you try to set up a road-block.

Cheers,
Wol

The Rust for Linux project

tux3 — Thu, 16 Sep 2021 22:17:56 +0000

Thay may indicate that no one has given them cause to change their talking points.

I imagine there's a lot of scaffolding, core code, and example drivers to write. Perhaps that's why it takes more than a couple months for them to move to the next step.

If you feel they should abandon their efforts, or not organize conferences to talk about the project's status, you should certainly want to share a good reason why. I think everyone can agree that we'd all like to hear novel discussion points.

Architecture support

corbet — Thu, 16 Sep 2021 18:29:50 +0000

Rust does not yet work on all of the architectures supported by the Linux kernel; this was discussed a bit more in the later days (stay tuned). That's recognized as a problem and is one of the reasons why people are looking forward to the native GCC Rust compiler.