Every week or so there seems to be drama about some old dude shouting about how rust in the Linux kernel is bad. Given all the open hostility, is there easier way for R4L to continue their work?
I dont think that there is another way. They are gonna have to coexist with the old guard. The problem is, they are both right. Rust is the better language, its basically made for this task, but C runs everywhere, it has a much larger userbase, and introducing a second language into a huge low level program like Linux will make it much, much harder to maintain.
Why would you say that Rust is made for low level hardware interfacing? I am generally curious.
I was only alluding to the fact that its a low level language like C, but with a more modern design and safety features, not anything specific, sorry!
I once heard that a major problem is that you have to disable or work around Rusts safety features once you write hardware interfacing code like a os kernel
Rust, IMO, provides a set of convenient features (borrow checker, RAII, generics, sane operator overloading, opt in unsafety) while leaving out ones that get pretty invasive and are hard to use in an embedded context (exceptions, new/delete operators, GC).
The "let’s rewrite it in " trope only works in a small project. Doing it in large-scale years-old well-maintained projects is asking for trouble (especially if there are no unit tests) and friction.
Best way forward if they so insist is to refactor small bits without interfering with the existing code-base.
Best way forward if they so insist is to refactor small bits without interfering with the existing code-base.
I’m not sure they’re even doing that, I think the policy is that Rust code can depend on C code, but C can’t depend on Rust. So at the moment nothing can actually be rewritten in Rust, it’s only additions like new drivers.
it’s only additions like new drivers.
What prevents them from rewritting old drivers? Some sort of API incompability? I was under the impression they were doing just that.
I think the biggest issue would be a lack of interfaces to the C side code, they’re slowly being fleshed out and each one enables more functionality for the Rust modules.
e.g. the test Ext2 driver a MS dev wrote last year after enough of the filesystem interfaces got hooked up
But even then, I don’t think the maintainers would accept one that replaces the existing C driver, that’d break non-Rust builds and architectures, and that’s a sure-fire way to get Linus on your case. Best you can hope for is one that complements a C driver, and even then I think you’d need a good reason to have two drivers for the same hardware.
Writing a kernel in two languages when it has for its entire history been written in one is just asking for needless complexity.
If Rust wants to have a kernel, then perhaps port or re-write Linux in Rust from scratch as a separate project. Once it’s reached a point of being self-hosting, let ‘the market’ decide in an open competition.
If the Rust version is demonstrably superior and more secure, then it’ll naturally supplant ‘legacy Linux’.
You say it’s “needless” complexity. But that’s what’s up for debate, and most people, including Linus seem to disagree with you.
It’s not a matter of whether Rust is demonstrably superior and more secure, that it is seems to be the common understanding and agreement.
A new project matching reasonable Kernel feature-parity would be too much effort. It’s unrealistic.
The value is in moving the Kernel itself into a safer space and tool-space.
The idea that a technically superior solution would naturally supplant an earlier one with a huge market penetration and stability is wishful thinking. We see it in many areas. Without significant issues people at large will stay with what they know and what is popular.
Why do you think its a problem that this is discussed a lot? Its a huge deal, so its only good its discussed and not accepted by everyone. I think this is healthy. We only read about the drama and a few quotes, but if you look closer then their argumentation makes a bit more sense. It is not just drama for the sake of drama. Some maybe toxic, that is another thing, because they would be toxic with other topics too.
Here is in a videoformat from ThePrimeagen (programmer at Netflix, or he was, not sure about current state) going through a recent discussion in the Linux Kernel mailing list about this topic. It’s about a hour long and adds some thoughts on its own too, which was valuable to me. - https://www.youtube.com/watch?v=8QcQ_128OIw
Fork.
deleted by creator
There is no reason for it. The odds of success would be low compared to the current process which for the most part is going along pretty well despite all the melodrama surrounding it.
deleted by creator
There is no point in forking. The problem is not adding Rust to the Kernel, the problem is the C developers to get to work on it together. Forking does not solve this issue. Its not about proving being more efficient or not.
the problem is the C developers to get to work on it together.
Perhaps the problem is you wanting developers to work on something they don’t want to work on.
The problem is wanting to shoehorn a new language into an existing, long-standing large-codebase project.
Forking is the obvious solution but rustaceans know that’s a pretty daunting task…
The next best thing is to develop in parallel, refactoring parts (usually drivers) without interfering with the existing codebase.Forking does not solve the problem, it only escapes it. Its waste of time and effort in this case. The solution is that the devs work together. Otherwise it makes no sense to have Rust if no one works together. Discussion is the best way to handle this and to come to a solution. Its such an important topic that you have to discuss it, this is healthy, this is how it should be done. This is how its done.
If people can’t work together, forking usually “solves” the problem.
Let’s see if they end up working together.Forking does not solve the problem, it escapes it. The problem in the main Rust Kernel will stay, not working together, arguing, while the fork might work for those who work on the fork. This is not a driver or feature where they can fork, work on it separately. It completely misses the point.
