- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
cross-posted from: https://lemmy.world/post/25857381
Hellwig is the maintainer of the DMA subsystem. Hellwig previously blocked rust bindings for DMA code, which in part resulted in Hector Martin from stepping down as a kernel maintainer and eventually Asahi Linux as a whole.
People really afraid of Rust out here.
I can relate. I can emphasize with someone who’s learned every nuance of a language, and after 30-40 years suddenly these kids come in with their strange hieroglyphics slowly replacing everything you’ve worked on.
Except that’s literally the reality with computers. Everything evolves and things go obsolete. I’m sure the COBOL and Fortran programmers were pissed when the kids started using C too.
It literally wasn’t about Rust specifically though. Christoph literally said it was about anything that was not C, including assembly, C++, brainfuck, or whatever, entering the kernel. Christoph likes Rust. Christoph (rightfully) does not like mixed language codebases for projects as large and important as Linux
You make it sound like it’s a matter of taste rather than a technical one (and I suspect it actually might be just about taste in the end)
Its a little of column A, little of column B type situation.
Yes, some of it is his taste, but that taste is coming from a technical place. Primarily long term maintainability of the project.
I realize what Linus came out and said outlines that no code is entering Christoph’s part of the project, but Christoph is playing goalie and needs to make sure that never happens in order to keep everything working correctly for a very long time.
Maybe the DMA module gets rewritten completely in Rust one day, but until then, rust modules interfacing with a C-only component seems to be the best for long-term maintenance.
Not his call, as we can see now
But isn’t this in specific just about bindings?
Yea but if someone uses those bindings then you can’t just not support it.
By the time this code gets into a large scale production system it will be 2029. That is when the bugs will come in if someone leveraged the Rust bindings.
You can ask the big company users at that time to contribute their fixes upstream, but if they get resistance because they have relatively junior Rust devs trying to push up changes that only a handful of maintainers understand, the company will just stop upstreaming their changes.
The primary concern that a major open source project like this will have is that the major contributors will decide that interacting with it is more trouble than it is worth. That is how open source projects move to being passion projects and then die when the passion dies.
Instead of thinking about the bindings as part of the sub-system, think of them as part of the driver. That is what Linus is saying here.
The Rust code will be maintained, by those writing Rust code. By those writing the drivers. These are not junior people.
Except the bindings are written so that they can be used not just by this driver but others as well.
If companies write crappy code that calls into these bindings, that is nothing new. They do that today with C. Like C, the code will not be accepted if crappy and / or there is nobody credible to maintain it.
None of this is a good argument for not letting these bindings in.
It appears so now, yes, but when the drama initially came out it sounded like they were asking for a tiny amount of rust in the kernel to make it work, or if not rust, changing the C to tailor it specifically to the rust. Which I think is a reasonable thing to be concerned about from a maintainability perspective long-term, especially if the rust developers decide to leave randomly (Hector’s abrupt quitting over this very issue is a prime example).
A bunch of people were trying to make that argument to explain Hellwig’s disagreement, but it was never the case. His argument amounted to “you can’t make create unified code to reference mine, you must have each driver maintain its own independent calls to my code”.
Rust is straight up better than C. It’s safer and less prone to errors.
It’s not feasible to convert the entire Linux codebase at once. So your options are to either have a mixed codebase, or stick with effectively Cobol into 2020.
Rust is great, but you are not thinking from a long-term project perspective. Rust is safer, but Linux needs to be maintainable or it dies.
Based on what you’re saying, the only way its going to reasonably be converted to Rust is if someone forks Linux and matches all the changes they’re making in C as they happen but converts it all to Rust. Once its all converted and maintainability has been proven, a merge request would need to be made.
That is not how it will happen, if it ever fully converts at all.
Rust will first be added in a way that allows it to run on top of existing C code. That is what we are seeing here with Rust being used to write drivers.
As sub-systems get overhauled and replaced, sometimes Rust will be chosen as the language to do that. In these cases, a sub-system or module will be written in Rust and both C code and Rust code will use it (call into it).
The above is how the Linux kernel may migrate to Rust (or mostly Rust) over time.
As devs get more comfortable, there may be some areas of the kernel that mix C and Rust. This is likely to be less common and is probably the most difficult to maintain.
Nobody wants to rewrite working, solid kernel modules in Rust though. So, it seems very likely that the kernel will remain mostly C for a long, long time. There are no doubt a few areas though where Rust will really shine
No need for a fork or a rewrite.