LWN: Comments on "Resistance to Rust abstractions for DMA mapping"

Rambling

andy_shev — Sun, 02 Mar 2025 20:28:03 +0000

The first statement is an obvious mistake. The Rust thingy is way too young in comarison to the Linux kernel project (and even younger if you look at the first considerations to use Rust inside Linux kernel).
The last statement is also false. LK is the project of the community, and it is his project as well as Linus' or Greg's.

Time to step up, Linus/GregKH

daenzer — Wed, 19 Feb 2025 13:53:36 +0000

> Yeah, well, that's the point: the case *was* about technical issues,

The text you quoted from my previous comment was in response to "the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint". If a maintainer raising technical issues in patches is "difficult to make sense of from a purely-technical standpoint", maintainers might as well pack up and go shopping.

> those being that adding the Rust bindings uncovered ambiguities and whatnot in the C interface.

Don't think they really "uncovered" anything, the maintainer was already aware of the issues and explained them to the patch author.

> But when a maintainer then refuses to engage with the reporter (and instead replies with the kernel ML's equivalent of the "Everything's fine" meme GIFs that's ubiquitous on the 'net) the case ceases to be a *technical* problem in the strict sense of that word.

Having witnessed that discussion first-hand, I disagree that the maintainer refused to engage with the patch author. There was clearly a communication breakdown, the maintainer isn't solely responsible for that though. Communication is a two-way street.

Do you have a reference to back up the "Everything's fine" claim? My recollection is more like "the patches can't be merged due to these issues", which doesn't imply "everything's fine".

Time to step up, Linus/GregKH

smurf — Wed, 19 Feb 2025 10:27:23 +0000

> The case with Asahi Lina was about technical issues

Yeah, well, that's the point: the case *was* about technical issues, those being that adding the Rust bindings uncovered ambiguities and whatnot in the C interface.

But when a maintainer then refuses to engage with the reporter (and instead replies with the kernel ML's equivalent of the "Everything's fine" meme GIFs that's ubiquitous on the 'net) the case ceases to be a *technical* problem in the strict sense of that word.

Time to step up, Linus/GregKH

daenzer — Tue, 18 Feb 2025 09:42:31 +0000

> In the case with Asahi Lina, that was over code that was *broken* with or without Rust, the issues would have been visible even with a
> pure C driver, but the maintainer was rejecting her opinion on the basis of being a "Rust person talking about lifetime issues" despite this.
>
> In both cases the oppositional stance of the maintainers is extremely difficult to make sense of from a purely-technical standpoint.

I respectfully disagree that these two cases can be classified the same like that.

The case with Asahi Lina was about technical issues[0]. Raising technical issues in proposed patches is the job of a maintainer. No DRM maintainer said anything like "I don't want Rust in the kernel" or "Rust is cancer".

[0] You're right that the same issues might have affected C patches, and they would have been raised the same way then. In fact, similar issues were raised in C patches many times before.

Rambling

daenzer — Tue, 18 Feb 2025 09:18:56 +0000

Not really seeing much similarity between these two situations (admittedly having witnessed only "the DRM fiasco" first-hand). The latter was about technical issues in the proposed patches, no DRM maintainer said anything like "I don't want Rust in the kernel" or "Rust is cancer". Raising issues in proposed patches is the job of a maintainer.

Momentum

taladar — Mon, 17 Feb 2025 15:33:30 +0000

There is a meaningful difference if your C driver is not accepted into upstream because nobody wants to maintain two drivers for the same thing, especially if the one with fewer people who would want to maintain it comes after the other one. Now, I would consider it a good thing if C drivers are rejected because of existing Rust drivers (though we are not quite at that point of course) but I can see how the people who want to pretend Rust doesn't exist forever wouldn't like that situation.

Time to step up, Linus/GregKH

taladar — Mon, 17 Feb 2025 14:55:32 +0000

There are really only two options that avoid the scenario you describe.

You can either remove all the features that might potentially be affected by any code touched by any maintainer who does not know how to fix every single consequence of that code change exhaustively. You essentially turn the Kernel into a Hello World because that is likely most features.

Or you can restrict any maintainer from touching any code where they can't exhaustively fix everything that might potentially be affected by their code change. In that case the Kernel will likely never be changed again.

The problem you describe is not a Rust problem, it is a problem with an inability to work as a team.

Momentum

sammythesnake — Mon, 17 Feb 2025 12:30:30 +0000

The thing is, though, that "I need this Rust driver and there's no C driver alternative" differs from "I need a driver and there's no driver at all" only in the availability of a Rust driver. To somebody who won't/can't use the rust driver, the two situations aren't meaningfully different, and the classic response is "somebody with the motivation/means should write the driver (in C)"

There seem to be some people who think the availability of a driver they don't like is some kind of horrible situation, but I'm not frankly very sympathetic to that position. Just set CONFIG_RUST=no and get on with your life (possibly writing a driver in C if you have sufficient motivation/ability)

Cancer?

LtWorf — Mon, 17 Feb 2025 08:12:42 +0000

???

You keep talking about kernel and it was referred to user space. Since I even spoke about distributing and dependencies, which are very different on the kernel… That's because the comment I was replying to was wondering why would anyone still use C in general.

Cancer?

smurf — Mon, 17 Feb 2025 07:38:40 +0000

The awkward moment when you reply before thinking about what you're replying to, and then realize that you completely missed the point its author was making (or, apparently, trying to make)?

For the record, I didn't miss that line at all. I merely disagree, rather vehemently in fact, with your "C is easier" point. Because it definitely isn't. Not by the time you need to use nontrivial interfaces … like the rest of the Linux kernel, which I assume is still the context of this discussion.

C (and even more so, assembly) is not at all explicit in the sense that the interfaces to existing code are full of implied assumptions you need to adhere to, otherwise your code is buggy and will crash on you (or randomly corrupt your users' RAM, who knows). By contrast, in well-written Rust interfaces most of those cannot-be-stated-in-C-much-less-assembler assumptions are right there and the *compiler* will *tell* you if you violate them.

Cancer?

LtWorf — Mon, 17 Feb 2025 06:09:08 +0000

> Arguably it's not. [...] rules and restrictions *do* exist in (kernel) C

The awkward moment when you reply before reading what you're replying to, and you miss the line: "As for rust in general, there's a number of reason to still be using C now:".

You're basically arguing that python is harder because it has more hidden gotchas.

Is assembly easy since it's completely explicit then? Should we be using assembly directly? Should you have read my comment before replying to it?

(for me it's no, no, yes)

Cancer?

smurf — Sun, 16 Feb 2025 19:05:50 +0000

> * C is easier

Arguably it's not.

It just looks easier. C definitely has fewer syntax rules and fewer restrictions than Rust.

The problem is that those rules and restrictions *do* exist in (kernel) C, it's just that the compiler doesn't help enforce them, let alone emit helpful (no scare quotes – Rust is reasonably good in that regard) error messages.

Instead you get to learn the rules by experience and/or reading the sources of whatever code you call, code review that hopefully finds some of the more egregious problems, debugging crashed kernels, followup patches that fix your mistakes, and so on.

Speaking of code review. There's only so much mental bandwidth. Making sure that the code in question obeys the locking rules du jour, doesn't have use-after-free problems, and so on, means less focus on the actual logic.

Cancer?

LtWorf — Sun, 16 Feb 2025 13:23:08 +0000

Reading comments here of people who are kernel developers, I have had the impression that r4l developers are in no position to make that promise and keep it.

As for rust in general, there's a number of reason to still be using C now:

* can build and run for a lot more devices
* C is a well established language and it's easy to get stuff into distributions
* A lot of dependencies won't have bindings or equivalent for rust
* C is easier

Cancer?

sammythesnake — Sun, 16 Feb 2025 10:55:13 +0000

> remember that Rust is there to attract new contributors

That is certainly something to be hoped for, and for some is a motivating consideration behind pushing R4L, even a stated aim, but I think the far stronger motivation is the fact that Rust has very definite advantages over C as a language to implement kernel functionality in.

IMVHO (as somebody who has written zero Rust code, zero Kernel code, and maybe 150 lines of C code ever, "VH" gets some emphasis here!) I see so many reasons *not* to use C when there's any alternative that I'm frankly perplexed at the resistance some have to Rust.

Rust certainly has imperfections (as a bystander, even I can name a few) but anything that makes whole classes of bugs all but impossible is a no-brainer to me without something *major* to push back the other way.

The current controversy saddens me greatly - the R4L people aren't asking the current maintainer to do anything extra to support their work, and yet he's applying a veto on the basis that he doesn't want to do extra work. Frustrating indeed.

It seems to me that the correct way to manage this is for the R4L wrappers to go into mainline via a separate tree that Linus can pull from without other subsystem maintainers having to worry about them at all. In an ideal world, people working on the C code these wrappers talk to would cooperate and maybe even assist, but at the very least they shouldn't use their position to mess up stuff that doesn't hurt them.

There seems value here to the maxim "Lead, follow, or get out of the way"...

Deeper problems in the Linux kernel

lacos — Sun, 16 Feb 2025 00:12:14 +0000

> He should step away and learn Rust.

I think the only time you can justifiably wish for a maintainer to step away if they are non-responsive (which isn't the case here). When they clearly and timely object, then "should step away" is an unjustified expectation; they *are* doing what they promised to do as a reviewer: namely, to comment on contributions. If you don't like their point, you can fork the code, or try to route around them (eject them from power, perhaps by escalating to someone higher up).

Deeper problems in the Linux kernel

lacos — Sun, 16 Feb 2025 00:03:10 +0000

> The maintenance part *starts* once the code gets merged

One of the best comments I've ever read on the internet (not just on LWN).

If you are a maintainer, then one way or another, you *will* be held responsible for any symptom that emanates even a *whiff* of your subsystem. You'll indeed be asked to triage it, and oftentimes, confidently saying that the bug is in some other (particular) subsystem or layer, requires reproducing and *completely* tracking down the bug. Sometimes you know *where* it is only when you learn *what* it is.

> Others might just simply feel overwhelmed and decide to silently resign

Right; that's what I've done once in the past, when I found myself in a somewhat similar situation as a co-maintainer in another project (I disagreed with both the feature and how exactly it was being developed). This is ultimately a fight for power (= who dictates what direction the project follows). Not everybody has the oomph that Christoph does, to take on the fight (I'm saying this *without* praising his particular style) -- I did quit (not silently, but civilly for sure).

I think Christoph has every right to resist a direction that he perceives as disruptive to his ability to maintain a project to which he has dedicated decades of his life. If he doesn't budge -- some differences may be irreconcilable --, the proponents of Rust can fork Linux, or can try to eject or marginalize Christoph.

We should be aware that "forking" is older and broader than "forking a software project". Here's an example:

https://en.wikipedia.org/wiki/Vienna_Secession

(And the funniest part of it: "the [seceded] group *itself* split, when some of the most prominent members [...] resigned in a dispute over priorities" (emphasis and light editing mine).)

Time to step up, Linus/GregKH

lacos — Sat, 15 Feb 2025 23:30:04 +0000

> build with CONFIG_RUST=n

Not good enough *if* calling the kernel "releasable" requires "CONFIG_RUST=y" to build.

- The maintainer starts work on a branch at whose fork-off point the kernel is "releasable".
- The maintainer changes C APIs.
- The maintainer fixes up all C-language call sites across the tree.
- The API changes break the Rust bindings.
- The maintainer doesn't care (or even notice) because they build with Rust disabled. Even CI may pass for them, that way. (They might also have some customization for git-grep in order to exclude Rust source files altogether -- i.e., they wouldn't see any API call sites they wouldn't want to fix up.)
- The result is however, *presumably*, an "unreleasable" kernel, because "CONFIG_RUST=y" no longer builds.
- The maintainer ultimately performed a series of actions that turned a releasable kernel into an unreleasable one.
- The Rust-proponent maintainers now have to come in and clean up "after" the original maintainer, in order to restore the tree to "releasable" state.

I perceive this process as one manifestation of Hyrum's Law. I can see why the maintainer wouldn't want it.

Rambling

LtWorf — Thu, 13 Feb 2025 16:04:56 +0000

Don't take this the wrong way but given the amount and content of comments you post here, I think in your team you're most likely to be the most hard to deal with.

Rambling

Wol — Thu, 13 Feb 2025 10:16:58 +0000

> Sure you can try. But the chances of you succeeding to do that are really slim.

Is the guy a genius? Or is he a liability? Or is he both and which one outweighs the other? Managers are paid megabucks to make that decision (and if they take the money and don't do it, THEY are the liability ...).

But you pays your money and you makes your choice. I've actively declined (or pushed the manager for that decision) to hire somebody who was extremely capable. Because I (and everybody else) thought he would be a personal liability despite being clearly a technical genius.

Cheers,
Wol

Rambling

LtWorf — Wed, 12 Feb 2025 23:53:20 +0000

> Because, if you did, the proper outcome in that case is probably that your boss would fire you and that Pedro would take over. He would probably need to hire somebody to help.

This capitalistic view that any worker is replaceable at any time with any other worker clashes very hard with the reality where this doesn't work at all :D

Sure you can try. But the chances of you succeeding to do that are really slim.

Rambling

jmalcolm — Wed, 12 Feb 2025 20:50:06 +0000

You are the one that introduced the "boss" concept into the mix. Replace "Linus" with "community" or "LKML" or some other concept that you prefer.

To extend the thought experiment though, without getting into a long debate over the politics of the kernel, let me ask you a question. Can Linus "fire" a kernel maintainer? Because, pragmatically speaking, I think the answer is "yes".

Linus has ultimate authority over what code gets merged into Linux. That this is a fact should not be controversial. That is, he can decide who to accept patches from. He can provide public guidance to others as to who he will accept patches from and what sub-systems he will accept those patches from. If Linus can remove a maintainer from their job and replace them with somebody else, I think that saying that Linus can "fire" a maintainer is a reasonable simplification of language.

For the purposes of this conversation, I think we can agree that calling Linus "the boss" is a similar simplification of language. He has exactly the same attributes as my boss does in terms of how much power my boss has in forcing me to align with his views. Historically, Linus has wielded that power and done so quite effectively. Pretending that he has not or cannot is not an argument in good faith.

Rambling

jmalcolm — Wed, 12 Feb 2025 20:36:45 +0000

If you are going to accuse people of not understanding, you should make sure you understand things yourself.

Your analogy falls down because that is not what happened. At all.

What would you say if your boss said: "We need some extra capabilities to stay competitive. It is going to mean some new skills and some extra work. So, Pedro here is going to help you. He is going to do this part and you are going to do that part. There may be some small changes to the way you do things in the future but, good news, it will not be any extra work for you because of Pedro here."

Can you honestly say you'd be like "uh, forget it boss. I do not share your opinions. We do not need to do that work. We do not need those outcomes. I won't do it. Not happening. Get over it."

Because, if you did, the proper outcome in that case is probably that your boss would fire you and that Pedro would take over. He would probably need to hire somebody to help.

See the difference?

The objection here was not to "the extra work". It was to the intended result. He flat out rejects that a mixed language code-base is better. He does not agree that adding Rust to Linux will make it a better kernel. So, he is blocking it. Sure, the "boss" (Linus) already decided that it was a good idea and that it should happen. He disagrees. So he does not care what the boss said. He is not playing ball.

Re-read your analogy and mine. See the difference?

Rambling

Cyberax — Tue, 11 Feb 2025 17:17:30 +0000

Large companies are backing Rust, including Google for Android. Binder was one of the first real Rust drivers.

Rambling

andy_shev — Tue, 11 Feb 2025 15:25:43 +0000

Irrelevant. For RT Linux were real customers behind with $$$, behing Rust no-one with $$$. Or if you are talking about DMA mapping in C, that's another story.

multi-language code base

taladar — Mon, 10 Feb 2025 10:07:04 +0000

Maybe the output is only 2000 lines a year because figuring out what exactly that C++ did and why took such huge amounts of time. If you need to closely examine 20000 lines of C++ for every 100 lines you write and then mirror every idiosyncratic detail of the original behavior I could see a very low output as the result.

Relative difficulty

taladar — Mon, 10 Feb 2025 09:49:53 +0000

Try, but to be fair, FFI code is harder to write in any language than the average piece of code just using that language because you generally need to understand both languages and often C as well because bindings often go through a C-like interface even if neither of the two main languages are C.

multi-language code base

sunshowers — Sat, 08 Feb 2025 19:53:14 +0000

Oh, and I forgot to mention that this wasn't just 2000 lines of new code a year—this was 2000 lines of a rewrite of a C++ project per year. That's the sort of thing that goes way quicker the second time.

To put it bluntly, if my code output was 2000 lines a year, and I didn't have a very good justification for it (like spending most of my time doing non-code related things), I would have been fired for underperformance.

multi-language code base

sunshowers — Sat, 08 Feb 2025 19:44:43 +0000

I like to think I'm an okay programmer, and my code output tends to be somewhere around 50k-75k lines of production code a year, on top of all of the other responsibilities of a senior engineer (planning, writing, documentation, learning/teaching).

2000 lines is the sort of figure you would achieve if you couldn't leverage modern tooling to offload as much thinking as possible to the compiler and other automation.

I pay a huge amount of attention to tests too, and in fact one of the things I maintain is a free (libre), cross-platform test runner for Rust that attempts to use state-of-the-art concepts to be the highest quality test runner in existence.

Learning Rust

ssokolow — Sat, 08 Feb 2025 03:27:40 +0000

"Must still uphold all safe Rust invariants. You just get access to new constructs with more lax rules," aside, when people well-versed in Rust say unsafe Rust is harder than C, they're often referring to one specific footgun-for-C-programmers case which has since been made less serious with the introduction of the &raw operator in October 2024.

Basically, that, no matter how hard you try with typecasting, the & operator will create a temporary & or &mut (non-raw) reference which must uphold the validity invariants, so it's instant UB to use it to construct *const or *mut (raw pointers) which alias in situations where legal-with-raw-pointers aliasing is allowed.

Previously, you had to use the non-obvious std::ptr::addr_of! and std::ptr::addr_of_mut! macros to take raw-pointer references to things without being required to uphold the aliasing invariants.

Rust Developer words and actions do not align

ssokolow — Sat, 08 Feb 2025 03:27:25 +0000

To be fair to the piano, I don't think it originated that behaviour. As I understand it, the harpsichord occupied more or less the same niche before the piano was invented. That's why there's so much harpsichord music.

Hector Martin resigned

foom — Fri, 07 Feb 2025 21:37:28 +0000

Well, apparently now this situation has now resulted in Hector Martin resigning—apparently after he first instigated some social media "brigading" of some sort.

It's unfortunate, because I thought his earlier email was a great suggestion—recommending that Rust-for-Linux folks should not waste any more time debating with hostile maintainers, and just wait for Linus to decide whether to pull the patch series or not. Following his own recommendation there seems like it could've resulted in leaving space for the right thing to happen, without creating additional drama...

Relative difficulty

pbonzini — Fri, 07 Feb 2025 16:48:28 +0000

In all fairness, bindings code is significantly harder to write than your average Rust code, because it has to express formally the safety requirements of the API. So it encompasses understanding the C code and being able to express its semantics in Rust.

New contributors

Wol — Fri, 07 Feb 2025 16:35:28 +0000

> I'm sorry, I didn't make my point clear.

And you don't seem to have understood mine.

If my boss tells me to do something I find unpleasant, I will not want to repeat the experience! And in jurisdictions where "hire and fire" is not the norm, my boss will find it very hard to make me do it again. "Give it to someone else!". Payment has NOTHING to do with it.

And if the boss can't find people willing to interact with the kernel community, that could be another reason why so many companies ship outdated kernels with their gear - it's not that they don't want to ship updated stuff, it's that they can't find staff willing to go through the grief of upstreaming the stuff they need ...

(People of that calibre are likely people that could just walk if they so desired ...)

Cheers,
Wol

New contributors

pizza — Fri, 07 Feb 2025 15:24:27 +0000

> But companies have motivation (or rather the people within them do). If the kernel community actively demotivate outsiders - paid or not - that's a bad thing.

I'm sorry, I didn't make my point clear.

Companies pay folks to contribute stuff, but once that "stuff" is contributed (eg add a new driver or a fix for an existing driver) from their employer's perspective, there is no longer any need for those folks to continue engaging with the kernel as a whole, so they are tasked with doing other things instead. Voila, drive-by contribution.

While those individuals _could_ continue to do other things with the Linux, but that would have to come from their off-the-clock time, and unlike $dayjob where you do what you're told, on one's own time there are innumerable other things you could do. Such as being with with their families or going outside, ie "anything other than spending even more hours staring at a computer screen performing unpaid, hard, thankless *work*)

In order to gain the level of expertise and experience necessary to rise up to the level of a subsystem maintainer, one has to spend literally *years* getting your hands dirty on Linux's internals on a more-than-full-time basis. Very few folks have the opportunity to do so.

New contributors

Wol — Fri, 07 Feb 2025 14:54:10 +0000

> they no longer have the time (and/or motivation) to continue.

But companies have motivation (or rather the people within them do). If the kernel community actively demotivate outsiders - paid or not - that's a bad thing.

What's the difference between the kernel community de-motivating contributors, and a company de-motivating customers? NOTHING. Both are actively shrinking the pool of people willing to do business with them, and both are actively hastening their own demise.

Whether I'm paid or not has nothing to with whether I have a bad experience or not. And if I have that bad experience, next time I'm asked to go back there I will actively resist. If I'm paid and my boss has to pull rank, that puts him off and makes him less likely to want to deal with them too.

Even - or especially! - if they're paid to do so, you do not want to give the people the motivation to NOT come back.

Cheers,
Wol

Learning Rust

foom — Fri, 07 Feb 2025 14:40:19 +0000

I thought this thread was about Learning Rust, not Learning English! Nevertheless, I'm just going to quote Wikipedia, Exception that proves the rule:

Two original meanings of the phrase are usually cited. The first, preferred by Fowler, is that the presence of an exception applying to a specific case establishes ("proves") that a general rule exists. A more explicit phrasing might be "the exception that proves the existence of the rule." Most contemporary uses of the phrase emerge from this origin, although often in a way which is closer to the idea that all rules have their exceptions.

The article does then go on to describe a few other ways in which the phase may be interpreted, including the meanings which people are arguing are the only possibly-correct meaning in this thread.

So, go ahead and keep using it in those ways if you wish, but, please do be aware the above is the meaning intended by the vast majority of English speakers using this phrase—and it's not "nonsense" to use it in that way.

New contributors

pizza — Fri, 07 Feb 2025 13:15:29 +0000

There is also a very good chance that the overwhelming majority of folks that make one-off contributions are being paid to do so by their employer, and once accomplished, they no longer have the time (and/or motivation) to continue.

Copy it but keep it the same

taladar — Fri, 07 Feb 2025 12:47:04 +0000

Lets be real here, if the goal of the RfL people was to write a kernel entirely in Rust it would be much easier to write one from scratch than to fork the Linux code base with its decades of cruft that has to be learned and worked around, especially if there was no cooperation in that learning process from existing maintainers.

multi-language code base

taladar — Fri, 07 Feb 2025 12:31:16 +0000

A large reason why C++ is all first party is probably also because C++ tooling to create separate libraries is so incredibly painful to use that it incentivizes people not bother unless they have a very good reason to do so, leading to much worse code reuse than the language itself could support.

multi-language code base

taladar — Fri, 07 Feb 2025 12:29:28 +0000

I think the third-party question is asking the wrong question. The real question should be how much of that was written with Firefox as its first major user and how much of that is only used by Firefox now (not reusable despite being a library crate).

If anything having huge amounts of code directly in your code-base without any split into libraries is a code smell, the next best thing is code only you can use but that is at least properly split into theoretically reusable libraries with a well defined interface and the best option is using reusable code that can be used for other projects too.