Rust developers are frustrated with Linux C kernel developers.
Rust developers are frustrated with Linux C kernel developers.
cross-posted from: https://lemy.lol/post/30414136
Wedson removing himself as maintainer of the Rust for Linux project.
45 comments
-
-
In the spirit of making suggestions, as this frustrated Rust developer was doing, and in the spirit of reducing vulnerabilities, as Rust itself is trying to do:
Screen shots on lemmy are mostly hosted on remote sites, so they don't show up for people who block off-site media (e.g. to avoid tracking). They don't work with screen readers (e.g. for the vision impaired). They don't work with search at all.
And since Mastodon won't show anything unless the visitor allows javascript, and since it's a distributed platform instead of a single well-known site, a would-be visitor would have to allow javascript on random web sites in order to view Mastodon posts. That would expose them to tracking and browser exploits.
For these reasons, quoting the text you want to share would be better than screen shots or Mastodon links, for convenience, utility, and safety.
-
Full text of the post by Asahi Lina (@lina@vt.social):
I regretfully completely understand Wedson's frustrations.
A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.
When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.
That simple concept only recently finally got merged, over one year later.
When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".
My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".
Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.
One C driver works, so Rust drivers must work the same way.
Making the Rust bindings safe would have required duplicating much of the functionality of the C code just to track things to uphold the lifetime requirements. It made no sense. It would have been easier to just rewrite the whole thing in Rust (I might end up doing that).
To this day, bugs in the DRM scheduler have been the only causes of kernel panics triggered via my Apple GPU driver in production.
The design of that component is just bad. But because I come from the Rust world, the maintainer didn't want to listen to my suggestions.
If it takes a whole year to get a concept as simple as a trivial "device" wrapper upstreamed (not any device model functionality, literally just an object wrapping a struct device so we can pass it around) then how is Rust for Linux ever going to take off?
Rust works. I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.
Because I wrote it in Rust.
But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better.
-
There are some situations where I can see Rust's type-ststem potentially being counterproductive. For instance, it may be valid to invert lock order in a chain of operations under some circumstances, and rust might prevent you from expressing that. I grew up with C (from the pre-ANSI days) and while lifetimes and ownership are things that good C devs care about, they are tacit - and the ability to play fast and loose when necessary is great.
The linux kernel is built on a foundation of these implicit semantics. Some of it is written down, some of it isn't. I can see why asking "but what does this mean?" can lead to frustrating conversations and overly-qualified answers, but not everyone in that video was hostile to the prospect.
-
Is that not what
unsafeis for?-
It's what C is for, too.
The point is that there may be cases already where the type system that rust provides its guarantees off the back of is insufficiently expressive. (I say "may be" because there are ingenious qays to use what it does provide, although nonobvious and not necessarily without cost.) If you're using
unsafethen it's just an uglier C. I don't think anyone considers the current state of Rust's type system to be the be-all and end-all of expressivity.
-
-
-
Based C devs.
The rust road WILL be built, the rust hotel WILL be built, and fuck whoever the land belonged to and all the previous infrastructure. They'll simply replace everything with Rust™ built infrastructure.
Rust wants to force itself into everything and to change everything it needs to get itself working, and for some reason it has a cult defending all of its moves to make everything Rust™ compatible.
This shit is getting ridiculous.
-
C developers are basically the angry neighbor complaining that the city is building a bike lane.
Biking is really popular these days, because it's healthier, cheaper, and better for the environment than driving, but new residents moving to the neighborhood will only move in if there's good bike lanes. Now, nobody is asking the C developer to give up their car, but they're still mad about the bike lane. They can't be bothered to learn how to drive alongside bicyclists, and they say that bicyclists just have to deal with the fact that the C developers might run them over, and they should just get a car. All the bicyclists are afraid to use the bike lane because people keep getting run over by the C developer, and the C developer refuses to learn new driving techniques to share the road with bicyclists.
This eventually leaves to all the bicyclists moving to another city where they can bike safely, and the C developer's neighborhood turning into a shithole ghost town with no developers left, all because the C developer is an asshole who can't accommodate change.
-
-
tl;dr Language elitist salty that project owners don't want them to refactor in more bugs.
-
Am I misunderstanding? I thought there were existing bugs caused by unclear lifetimes, and adding a simple C wrapper would prevent those, and make Rust Interop easier at the same time? Which they eventually did, but it took one year?
Why does fixing bugs and making the API more solid = "refactor in more bugs"?
-
We have one side's unilateral description of how they perceive the existing state of things and their changes. Folks are very likely to poorly characterize things in a way that would sound crazy to disagree. However the truth is usually somewhere in between.
I have had very very vocal user that decry very deliberate design that the wider user base wanted as a "bug". If someone read their rant without the wider context one would think my team was unreasonable and producing bad software. Even after fellow users took time to explain why they wanted his request rejected, he was quite adamant that everyone else was wrong.
-
UB is only one class of error you can get in a big, complex program. Re-writing functionality opens the door to every other potential class of error too.
I liked the approach the kernel devs were taking where rust modules were being integrated without the 'core' code being touched. I think people who want a complete re-write of everything (if they exist outside of my convenient straw man) are probably better off starting a fresh kernel project.
-
Because that's the inevitability when major changes are introduced, especially when solely for purposes not directly related to bugfixes.
-
-
45 comments
The subject is considerably more complex and nuanced than expressed by these one or two (obviously frustrated) people. I won't presume to capture all the issues, but this person on HN does a decent job of capturing some of them:
And then there is this angle, which also exists:
The vibes I got in the other thread about Wedson's announcement is that the concerns may be valid but there are indeed a handful of contributors who are aggressively shouting down Rust contributor's efforts to set up the processes you outlined based on hard prejudice. The video Wedson posted was hard to watch. From the outside looking in it looks to be way more about ego than any particular technical roadblock.
Furthermore Lina's concerns here are only broader what you are saying:
Mainlining memory safety improvements, in C, for C code should be welcomed and it is very concerning if she indeed got shunned because the end goal was to offer lifetime guarantees (which to my admittedly non-expert eye sounds like it would be a good thing for memory safety in general).
Seems like a moral panic over absolutely nothing (where are the Rust developers allegedly forcing people to learn Rust? all I've seen in these threads today is Rust developers asking for an open mind and a willingness to collaborate), and that the response to this "concern" is to block any and all changes that might benefit Rust adoption is really concerning (but unfortunately not unsurprising) behavior.
It would be a good thing. Nobody is debating that. It's why Linus agreed to start experimenting with Rust in certain parts of the kernel.
However, trying to integrate one very specific approach to it into a large, already-working system that works quite differently, is a lot harder than writing from scratch one small component that mainly has to work in its own native ecosystem (as Lina has done).
Without good and realistic answers to how the long-term maintenance of such changes would be managed, it is myopically unrealistic to propose those changes, let alone to push this hard for them and be so dismissive of the folks who actually have the experience and responsibility to keep it all running. Especially when it's something that the entire world has come to depend upon in one way or another, as is the case with the linux kernel.
The problem isn't the immediate thing they're asking for; it's the inevitable chain reaction of events that will follow. They don't seem to understand the bigger picture, so they don't have answers for how it would be managed. The obvious but unstated solution would be that many kernel developers would have to invest an enormous amount of time (which they might not have) to become proficient in Rust and adapt an enormous amount of surrounding code to it, on top of their existing responsibilities. More than a few people (who are very much in a position to know) see that as unviable, at least for now.
No viable alternative has been offered. Hence the objection. And, since the vocal minority keep on pushing for their changes without addressing the issues that have been raised, the only sensible response is to reject their request.
If rust code relies on a C API (as it necessarily does), then a breaking change to the API requires changing that rust code. This is common sense.
If a process is set up for deferring rust maintenance to a rust developer, this can only last as long as rust maintainers are willing to staff it.
If C developers are unwilling to accept any risk of needing to touch rust code in the future, then rust contributions should not have been allowed in the first place.
Allowing rust contributions and then imposing restrictions on what can be done with it? That's not reasonable.
i can definitely see it as a “hostile takeover” of sorts, but this is something the project has decided on, for better or worse. i can understand not wanting to learn a new language that you may not like or agree with, but that means you will have to divest yourself from a project that adopts that language to a certain extent. Rust is—again for better or worse—something Linus thinks is good for the project, and thus learning Rust at least enough to not break the builds is a requirement for the project. i can’t imagine working on a software team where a chunk of people refuse to take part in a major portion of it simply because they’re not immediately familiar with it. that does sound like old crotchety behavior. on the other hand it’s tragic that so many people with all this experience are being forced into a design decision that arguably may have been made hastily and that they had little say in.
that makes this definitely an old guard vs new issue. and maybe it is an olive branch for the old guard to say “let’s just take our time with this.” but we have crossed a threshold where seeing a new project in C is the oddity while new projects in Rust are commonplace. Rust is mainstream now, and “i don’t want to learn this” is a dogshit technical justification.
That misrepresents the situation. Linus accepted Rust provisionally, and only into certain parts of the kernel (drivers). It's more of an experiment than what you wrote would suggest.
Rust is highly visible now, due in no small part to its deafening evangelism. But it is not remotely mainstream in the sense of being a prevailing language, nor in the sense of being representative of the majority. It brings to the table a novel way to solve certain problems, and that is useful, but let's not mistake that as the only way or those as the only problems.
That is a straw man.
I mean, if you mean "Rustplaining is commonplace", yeah.