Mixing Rust and C in Linux Likened To Cancer By Kernel Maintainer (theregister.com) 90
A heated dispute has erupted in the Linux kernel community over the integration of Rust code, with kernel maintainer Christoph Hellwig likening multiple programming languages to "cancer" for the project's maintainability. The conflict centers on a proposed patch enabling Rust-written device drivers to access the kernel's DMA API, which Hellwig strongly opposed. While the dispute isn't about Rust itself, Hellwig argues that maintaining cross-language codebases severely compromises Linux's integrated nature. From a report: "Don't force me to deal with your shiny language of the day," he [Hellwig] wrote. "Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that's not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I'm concerned." This resistance follows the September departure of Microsoft engineer Wedson Almeida Filho from the Rust for Linux project, citing "nontechnical nonsense."
"Linux is worse than cancer" (Score:1, Insightful)
Re: (Score:2)
Re: (Score:2)
We thought we stamped those fuckers out back in the 40's. Who knew those roaches would come crawling back out of the sewer?
Hopefully, enough us us remember how real American's deal with Nazi scum.
The unnecessary off-topic political thread (Score:2)
Turns out that you can't simply wipe out fascists once and be done with it. They're like terminates or roaches, and you have to keep wiping them out to keep the infestation at bay.
The Greatest Generation did the hard work. But Boomers and Gen X didn't keep up with the necessary maintenance. So kids, if you want to blame someone, blame your lazy, feckless parents.
Re: (Score:2)
I'd still blame the boomers. They're the reason why most of GenX has lead poison damaged brains.
Might explain why we have so many crazies right now in their 40s and 50s.
POTUS might skip my generation.
Re: (Score:2)
Fascism is a product of human nature. It takes continual work and deliberately choosing a different path to keep it at bay. Trump has certainly encouraged and fostered this natural human tendency towards fascism and has really empowered a bunch of people who've embraced their fascist nature, such as Musk. Trump himself can cause lots of destruction, but that's nothing compared to what will follow when he's gone.
Woke is worse than cancer (Score:2)
Team Hellwig (Score:5, Insightful)
Re: Team Hellwig (Score:5, Insightful)
Way to go with the straw men, but hey, hoped you enjoyed your sanctimonious rant.
Re: (Score:2)
At least they're not whining that someone wants to add some rust code to the rust/kernel source tree.
In a message to the Linux kernel mailing list, Hellwig wrote: "No Rust code in kernel/dma, please." For what it's worth, the patch added code to the rust/kernel portion of the Linux source tree, not kernel/dma, as far as we can tell.
To be fair (Score:2)
what? no (Score:4, Informative)
He's saying that he doesn't want to change the kernel interfaces to be more "rust-like" and if the rusty people want to write kernel code they need to conform to the existing interfaces. How you managed to get your deranged, lengthy opinion from what he said boggles the mind. Maybe there's a street corner where you can stand and shout your ignorant nonsense to other people.
Yes he is also saying that mixing rust and C is a bad idea for the simple reason that experts in one are not likely to be experts in the other (keeping in mind that there is a third, underlying requirement to ALSO be a world-class kernel programmer) and this is going to introduce bugs, but that is such a self-evident fact I have no reason to think anyone could argue with it.
The rusty people would love to slowly convert the entire kernel into rust, which is pretty much the definition of cancer (an infection that spreads and takes over the whole organism until it kills it) so I think he's spitting straight facts. Sorry if it hurts your feelings. Frankly I wish the rust people would all go work on Systemd so that project would die a painful death. If they could take the code-of-conduct retards with them even better.
what's the problem? (Score:4, Interesting)
Objecting to "enabling Rust-written device drivers to access the kernel's DMA API"?
It sure seems innocuous to me. There's an API, Rust could have access to it, why is that a problem? This particular Hellwig guy, who apparently doesn't know Rust, would obviously not be asked to maintain any of the Rust code so why should he care?
Re: what's the problem? (Score:2)
I must say, I'm kinda confused about what makes this a problem too.
I get that having multiple languages and some overhead. Yeah, granted.
But I thought part of the point of having an API is decoupling from a particular language.
Is this just a "get off my lawn" complaint from someone who doesn't want the world to pass him by (as it will all of us someday)?
Re: what's the problem? (Score:5, Interesting)
I must say, I'm kinda confused about what makes this a problem too.
I get that having multiple languages and some overhead. Yeah, granted.
But I thought part of the point of having an API is decoupling from a particular language.
Is this just a "get off my lawn" complaint from someone who doesn't want the world to pass him by (as it will all of us someday)?
Originally I agreed with you, but after re-reading TFS... it seems like the API is already there, but the rust devs want the API patched to better work with their rust code. That's what the guy is complaining about - it's a rust-specific patch to the API, which is the opposite of "decoupling from a particular language".
So why not just reject the patch and tell the rust devs "go ahead and use rust, but the onus is on you to make your code work with the existing API"?
Re: what's the problem? (Score:5, Informative)
I read it as the library API uses C conventions and the Rust types want an additional library with an API that uses Rust conventions. I assume Rust doesn't use C conventions like everything else because of some code safety thing.
I've seen decent sized projects that used multiple languages and they were a maintainability nightmare. Multiple versions of the same thing in or for different languages sounds worse.
Re: (Score:2)
I read it as the library API uses C conventions and the Rust types want an additional library with an API that uses Rust conventions. I assume Rust doesn't use C conventions like everything else because of some code safety thing.
If that is the case, then there is a solution: Create a shim library maintained by the rust developers that takes Other semantics and translates the library call to the C API. The Shim library could be written in Javascript for all I care; as long as one of the options offer
Re: what's the problem? (Score:2)
Hmm. That casts a different light. Thanks.
Re: (Score:2)
>> tell the rust devs "go ahead and use rust, but the onus is on you to make your code work with the existing API"?
As I read it, that's what they want to do but this Hellwig guy is opposed even to that.
"the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings."
Re: (Score:2)
If that's indeed the situation, it seems entirely reasonable. But I have trouble jibbing that with the mention of patching the API.
Re: what's the problem? (Score:2)
That's what I'm seeing as well. He wants each individual driver to have its own C bindings. That doesn't make any sense and feels like it would make things even more painful for maintainers.
It seems like he's doing exactly what Linus Torvalds was saying some developers do. In other words, it's going like this:
* Patch to rust/kernel submitted
Hellwig: kernel/dma is mine. Keep out
Ojeda: We didn't even touch it, we only created a common rust binding in our own chode to make runtime DMA access more ergonomic. Wh
Re:what's the problem? (Score:5, Insightful)
Because he is being asked to create data structures that don't make sense if you are working in C. IMHO Linus has made a huge mistake letting Rust into the kernel. I have never seen a multi-language project that did not suck. With small exceptions where something jython is included as scripting interface or something in a larger Java project.
One language is always the master, and the others are always second class citizens. You end up with a bunch of stupid glue and marshaling, coupled with dumb performance killing polling solutions or complex trampoline dispatch stuff because Lang-A can't call into Lang-B so you can't give Lang-A pointer to your Lang-B function. Finally for all your trouble you lose the really useful language features. Hey great we can crank out these modules in JRuby and leave the rest of of our project Java, yeah except the Ruby code ends up looking just like Java code because all the Java objects can't take blocks...
I have all the same experience with mixing VB and with C, and C with .Net and so fourth it really does not work.
The the johny-come-lately language people show up and say, our stuff works on the 32-bit build but breaks on the 64-bit build. You say well because you are doing pointer arithmetic and your environment does not understand the sizes of the primitives are different when the target is. Then it turns into can you embed the size of the structures somewhere ....
Its always a mess. Linux is C project, it should stay a C project. Do full port of the Kernel and primary user land to Rust if you want a Rust based system - it would probably be fantastic and more secure; but trying to cram Rust into C-Linux is just going to be a lot of suck.
Re: what's the problem? (Score:2)
Dont talk sense around here, the Rust fanboys will mod you to hell because Rust is the One True Language that will sweep all before it and must be shoehorned in to a multi million line C codebase Just Because.
Re: (Score:1)
You mean he's being asked to fully document the API?
There is a clear separation between C and Rust in the kernel. They're in different parts of the source tree. The dependency is also one-way.
It's helpful to Rust development if the C API is complete and every part of it is defined in code, not conventions.
This guy doesn't seem to want to maintain more robust C code.
Re: (Score:2)
Linux (like ALL Unix) is a C project.
If this were to be so, which it is not, then that would only serve to highlight severe design problems with Unix that a particular language would be required to write for it.
Re: (Score:2)
People are trying to, but this maintainer is refusing their patches.
No one is asking this guy to write any rust code No one is asking him to write any code at all. He's refusing patches, written in C, that describe the API without ambiguity.
Re:what's the problem? (Score:5, Insightful)
Yep, pretty much. And add that the Linux kernel is by now probably the largest software project that has ever succeeded and you realize that there is a delicate balance and upsetting that balance is a really stupid thing to do. Describing it as a "cancer" may be a gross understatement.
Re: (Score:3)
>> Because he is being asked to create data structures that don't make sense
I'm not seeing that anywhere. "a patch was submitted that would allow Rust drivers to use the DMA API's dma_alloc_coherent() C function to allocate and map large memory regions for direct memory access by hardware.", seems entirely reasonable. And "the patch added code to the rust/kernel portion of the Linux source tree, not kernel/dma". Hellwig would never have to look at any of that if he doesn't want to, it is being maintai
Re:what's the problem? (Score:4, Informative)
I'm not seeing that anywhere. "a patch was submitted that would allow Rust drivers to use the DMA API's dma_alloc_coherent() C function to allocate and map large memory regions for direct memory access by hardware.", seems entirely reasonable.
I don't see that either: the main argument is not wanting to have an additonal middle-layer abstraction. The rust guys seem to want a centralized API that can be reused by multiple differente device-driver, whereas the dma-api maintaner wants no middle-layer abstraction and want the device-drivers to deal with the abstraction themselves.
There is an acknowledgement that the middle-layer may introduce maintenance burden though. Reference here [kernel.org].
And "the patch added code to the rust/kernel portion of the Linux source tree, not kernel/dma". Hellwig would never have to look at any of that if he doesn't want to, it is being maintained by the Rust folks.
That has also been offered, but in the thread there are some counter-arguments, e.g.: this example [kernel.org]:
You'd have to reconcile that with the recent event where Linus defered the MM pull request and some C patches were dropped because of rust kbuild bugs:
All PRs to Linus must not break the rust build and the responsibilty for that falls to all the maintainers. If the Rust team is not quick enough to resolve any issues during the development window then patches must be dropped before sending PRs, or Linus will refuse the PR.
Also for reference, Linus' only reply so far is to criticize the attempt to social media brigading [kernel.org]:
Re: (Score:2)
That example kind of reads like 'people unwittingly breaking the Linux driver API are now made aware of the fact, and need to make sure it gets fixed before the PR can be accepted.'
Isn't it good practise, when building a public API to have multiple independent clients, to ensure your API is complete, documented and doesn't require special knowledge or tools to use?
Re: (Score:1)
He is not being asked to do anything.
Some developer is intending to add a .rs file with some bindings and to officially maintain it.
Hellwig doesn't want any .rs file in the kernel/dma. And, honestly, his only "technical" argument has been: "...so that it reminds greppable and maintainable"
I won't pretend to know if rust should be in the kernel code or not but I am fairly certain that arguments against rust code cannot be "to keep the code greppable".
There is obviously tension on the topic.
Re: (Score:2)
He is not being asked to do anything. .rs file with some bindings and to officially maintain it.
Some developer is intending to add a
He is having an implicit constraint added to his work as a developer that he can't make changes that break the Rust build which will now depend on his C code without seeing to it himself that the Rust code is updated.
Re: (Score:2)
It's not even that, no one wants to put rust code in kernel/dma
Re: (Score:2)
One language is always the master, and the others are always second class citizens. You end up with a bunch of stupid glue and marshaling, coupled with dumb performance killing polling solutions or complex trampoline dispatch stuff because Lang-A can't call into Lang-B so you can't give Lang-A pointer to your Lang-B function.
Thing is though that Rust has basically the underlying model of the machine as C and of course C++. They all represents fundamental types, aggregates and pointers.
C is very bare bones.
Re: what's the problem? (Score:5, Insightful)
You must be still at the age where you think all change is good regardless because ... change.
Newsflash - it isnt. Go google why multi language codebases are a bad Idea.
Re: (Score:2)
You must be the guy who's responsible for keeping strncpy() in the standard C libarary.
Can't change it. Even after 50 years. Never. There's nothing wrong with it at all, you just have to know how to use it.
Even if only 10% of C coders actually know how to use it, that's fine. Just make sure you always only hire the top 10% of C coders.
Re:what's the problem? (Score:5, Interesting)
Objecting to "enabling Rust-written device drivers to access the kernel's DMA API"? It sure seems innocuous to me. There's an API, Rust could have access to it, why is that a problem? This particular Hellwig guy, who apparently doesn't know Rust, would obviously not be asked to maintain any of the Rust code so why should he care?
The problem I heard last time around is that if someone wants to update the API (say) then they also have to update all callsites. Previously they could achieve this solely in C. Now they have to learn Rust as well to figure out how to update the callsites.
Re: (Score:2)
this is extreme masturbatory behavior that you'd expect from a dog or a 7 year old.
How about a 7 year old dog?
Re: Long live Redox (Score:2)
Yeah, it's not like 95% of the 40 million LOC in the Linux kernel and drivers aren't written in C. A full rewrite to a language with an unstable ABI is totally the way to go.
Re: (Score:1)
Its not like new project needs to implement many of those drivers. There are lot 'legacy systems' that might get Linux kernel upgrades, but will absolutely never be migrated Rust-ux without a hardware refresh as well.
Still a huge job sure; but so are most things worth doing.
Re: (Score:2)
It may well be worth doing, but it's unlikely to be getting done all at once. Better to get it done piece meal, converting the most critical pieces first. This requires proper bindings between languages. I also think the new language needs to be sufficiently mature and stable, especially the ABI. I have no personal experience with Rust, but my understanding is that it is neither of those things. It would be unfortunate migrating tens of millions of lines of code to Rust, only to have significant rewrites re
Why? (Score:5, Interesting)
But having a single project in multiple languages is a maintenance hassle. Rust is not an easy language to get into. It's gotten better, but in the early days every code example was either for an older version of Rust or a newer version of Rust (rustup wasn't around, and since when are we okay have a virtual env tool for a bloody system language?! You don't need that for most Go projects!)
If Rust is so great, why does it need special hooks in the Linux source code? Why doesn't it have functionality within the language to connect to existing C kernel header includes to build modules? It's literally a new language that's constantly broken. Why not just implement that? Why not just fix your stupid fucking language so you don't need the kernel team to do anything?
Rust is such a meme language. I'm sure it's an okay language, but I don't understand why it needs to be forced into everything. It's exactly like the type of people who use it, forcing their ideas and ideology onto a population that does not care.
Re:Why? (Score:4, Interesting)
The best answer is write a rust to c compiler (and a companion decompiler). That way you can write your code in rust, and I won't have to deal with it.
The problem with that answer is that language-to-language compilers tend to produce unreadable code. But if you maintain the rust code, and the compiler is good, that step won't be needed.
Consider, e.g., the Vala to C compiler. The C it generates is horrible, but valid. And people writing in Vala never need to look at the generated C. (I'm not actually sure how good that compiler is, but it's a convenient example. And it's used for interfacing with C code.)
Re:Why? (Score:4, Insightful)
Seems to be that not knowing exactly what the unreadable C code is doing might be problematic.
Re: (Score:3)
If you really want to, you can. It's just not easy. Compilers write code that's designed to be accurate and (hopefully) efficient. But I've never seen one that writes the kind of code a person would. (Well, I've only seen about 5 examples, so that's not a proof, just a strong indication.)
Re: (Score:2)
It's a driver. The driver is maintained in Rust. Everything a change is made it needs to regenerate the C code, but if it were C, it would need to be compiled anyway, so that's just one extra step, that can be automated.
FWIW, I tend to think of C a a "portable assembler". I know this is technically wrong, but it's about right. Move something to C and it can be run nearly anywhere. (And, IIRC, most of C could be handled by the M68000 assembler with a bunch of custom macros.)
Re: (Score:2)
I tend to think of C a a "portable assembler". I know this is technically wrong, but it's about right.
..claimed no low level programmer ever.
Stop confusing lower level with low level, and definitely stop trying to convince people that you are "better" than you actually are by claiming bullshit things about the high level language you use. I remember when you guys started claiming how low level you were and you met immediate resistance from actual low level programmers. You met it then. You meet it now. Just stop. Be genuine for once.
Re: (Score:1)
Or ideally, stop being a rust fag and learn C.
Re: (Score:2)
Seriously, no. Kernel code needs to be well readable. Another reason to only have one language in there.
Re: (Score:2)
Great. But if you're going to allow rust, then do it this way. The C code generated from the rust will be nearly unreadable, but optimizers to that converting C to binary (assembler) anyway..
Re:Why? (Score:5, Insightful)
That does not solve the issue. If you allow Rust this way, you massively cut down on the number of people that can run down and fix issues. And that is not good at all.
Re: (Score:1)
I was going to write a longer reply, but all those questions have been asked and answered so many times already that it would be pointless. This post is just pure flamebait.
Now, let me get off your lawn.
Re: (Score:2)
Why is there such a push to get Rust into the kernel? Memory safety? It's only memory safe up to the borders of the module, at which point you will need to make an unsafe call.
https://ferd.ca/complexity-has... [ferd.ca]
Complexity has to live somewhere. If your a skilled programmer then you find ways to keep the complexity in small well-defined parts of your codebase that don't leak out, are carefully documented, and are particularly well covered by tests. If you're not, then complexity spreads its way into all areas of your codebase.
Memory unsafety is very similar. And Rust has proved particularly good at keeping people honest about those "small well-defined parts" with respect to memory
Re: (Score:2)
Rust can call C code.
It's just better if the C API being used is written correctly and isn't full of untyped bullshit that is only documented in comments.
Proper structures and argument declarations help out everyone.
Re:Why? (Score:5, Insightful)
The Rust fanatics do not understand the limits of their language and that language used is just one aspect of a software project and its security. Essentially, this is aggressive incompetence.
The other risk, besides that a multi-language project of this size is an excessively bad idea and can only lead to project failure, is that Rust is really hard to learn. Getting it into major components will doom the Linux kernel, because there are not enough people that can keep it alive after that.
That said, I still think Linus only let these assholes and their fetish into the kernel to give them enough rope to hang themselves because they would not shut up and accept reality.
Re: (Score:2)
You're right. It would have been better to call it rust. Which happens to be colloquially called "cancer" by, e.g. car guys.
Also, man, trolls have gone down hill.
Yes..."safe" languages are a cancer in realtime (Score:2)
because they fool you into thinking you have a handle on timing or memory footprint when in fact there's stuff going on under the hood you're not aware off.
Even "hard" languages like C can fool you into doing something stupid. For example:
for(int i=0; i
can bite you in the ass in terms of execution speed, since even if the limit() function is straightforward and short and constant throughout the loop execution, the compiler has no way of knowing that and you buy yourself a function call overhead on each loop
Re:Yes..."safe" languages are a cancer in realtime (Score:4, Funny)
Also, while not Turing-complete and therefore possibly not the type of language we're talking about here, HTML can bite you in the ass. I mean, just one unescaped "<" and suddenly there's missing text and stuff is monospace for some reason...
Re: (Score:2)
I agree. Sure, if you write low-performance business code, all these features are nice. But as soon as performance matters, they just make it harder to understand what is going on. And that is why such languages have no business being in a kernel.
If you don't understand WHY this is a thing (Score:2)
If you don't understand why this is such a big issue go look at the chromium code base.
It's primarily a C++ code base and the rust cult members are also trying to convert it to rust and enable rust stuff but the rust stuff they added is so bad that it doesn't even use stable, and so this creates a lot of build problems and requires that one person that really isn't friendly to the Internet have a lot of power over that code base and so if you really want a good example of why you should care go look at the
Re: (Score:1)
requires that one person that really isn't friendly to the Internet have a lot of power over that code base
You mean Linus?
Maybe C is the cancer ? (Score:3)
If the mix is bad, maybe C is the problem? =ducks=
Re: (Score:2)
I know this was for funny, but it would be a valid stance if the project were originally in Rust and C people demanded a better interface.
That's really the issue, that for now, the project is a C based project with some Rust, and thus the onus is on the Rust to live in the ecosystem. Maybe one day it flips if the Rust people make a lot of progress, but right now the lay of the land is straightforward and inconsistent with the request.
It's all in the chemistry (Score:3)
Mixing Rust with AL would be even more problematic, especially if you're a hot head Kernel maintainer.
If Linux was a Rust based project.. (Score:2)
... I wonder how keen the fanboys would be to have C code included in it.
Hmmm.... tricky one...
Re:If Linux was a Rust based project.. (Score:4, Insightful)
If Rust had the Linux kernel as reference project, most of the criticism would fall away. But at this time, the Linux kernel project would never have succeeded in Rust. The language is immature and hard to learn. And the Linux kernel is probably the largest and most complex software project to ever succeed.
Mixing Rust and C Linked to Cancer (Score:3)
Did they test it on mice?
Tested on mice Re:Mixing Rust and C Linked to (Score:1)
and trackpads and keyboards.
typo, should be: *linked* to cancer (Score:1)
A recent double-blind study shows an increased risk for several types of cancer among kernel developers that use rust. This may be due to high levels of lead and other carcinogens in the actual rust that the language uses.
The REAL Problem (Score:2)
Rust, by itself, in theory, I personally don't have an issue with.
The tooling, however? Has been nothing but an absolute clusterfuck.
If you're Windows/Linux/MacOS on x86, you're great! Rust compiler will support you really well. But as soon as you're outside of this ecosystem, things start to turn to shit. Aarch64 isn't too bad, but beyond that, things go downhill really quick.
Sure, the overwhelming desktop and laptop world falls into this. But that's just end-user devices. Linux runs on a shitton more thin
CoC violation? (Score:5, Insightful)
I actually went and read the patch email thread. (Score:1)
It really seems like Hellwig is ideologically against any language other than C in the kernel and is pushing back on that principle alone.
There's no technical argument against the patch. Hellwig isn't being asked to maintain or work on any Rust code.
It doesn't even seem to be against Rust as a language.
It's basically a hard line of not allowing anything other than C in the kernel.
Agree or disagree about that position, but that really seems like what it is.
Now you understand mainframe systems (Score:2)
You've got a huge, heavily tested code base that's decades old, full of myriad edge cases and weird cruft but it works correctly. It's built in an old language that starts with a "C".
Changing it correctly would require documenting all the requirements, building 20 million test cases, and require people skilled in the existing language and the new language, and they need to be highly conversant in both. And dealing with unexpected hurdles that couldn't be foreseen by the world's top programmers, like the mai
I don't even like cmake in a project (Score:2)
Having Cmake, Make, Python, Perl, Bash and God knows what else just to build a project is already a nightmare. Too many languages in the build system already makes jumping in and being effective on a software project pretty tough. On top of that, having assembler, C, C++, and perhaps Ada or now Rust in a system software project means to contribute you often have to be reasonably competent in all the language AND have all the necessary toolchains installed.
The Linux kernel project's handling of Rust is prett
Finally get to use this (Score:2)
From a month and a half ago, a post about Rust [9cache.com].
This story is exactly that.
Old Guard vs New Guard (Score:2)
Firstly, if you are a kernel programmer, you shouldn't have a problem learning to read Rust if needed.
This isn't where the argument is. Well, that is exactly where the argument is, but not for the simple reasons you think.
Linux is famous for not having standardized internal ABIs in a lot of areas. Some see this as a critical to Linux being an success, other see it as a impediment to progress.
As far as Linus goes, he doesn't see any problem with Rust in the kernel, so it goes down the chain.
As I see it, this