Mixing Rust and C in Linux likened to cancer by kernel maintainer

Developers trying to add Rust code to the Linux kernel continue to face opposition from kernel maintainers who believe using multiple languages is an unwelcome and risky complication. Concerns surfaced last September when Microsoft software engineer Wedson Almeida Filho stepped away from the Rust for Linux project, citing …

[diodesign]

"it would suck"

I'm not sure how rewriting a C kernel in a C-like language with strict compile-time safety would make it suck. It might suck in that porting/converting millions of lines of kernel code is going to take some time, and in that time, the new kernel will be incomplete.

But like low-level C, Rust compiles down into GC-less machine code. It might even run faster in places as some run-time safety checks/mechanisms can be performed at build time.

And I suppose we should just call Rust what it is. Ada fan fiction.

C.

[GNU SedGawk]

Re: "it would suck"

Here's the thing.

I don't much like Rust. "strict compile-time safety" is magical thinking. Software is the state of the hardware, and hardware has bugs.

At some point a language that lets you force what you want into the correct shape and alignment for the use case, is desirable.

It's purely a desperate attempt to make Rust language relevant to anybody who's not a masochist.

[diodesign]

Not magical thinking

I like Rust. But I like Zig more because Zig just lets me code without Rust's obstinance, and with some safety, but not as much as Rust's.

Rust's compile-time safety is absolutely non-magical thinking. Have you encountered the borrow checker? No doubt there are ways to trick your way past it, or just turn it off with unsafe{}. But by and large, it's going to stop you doing silly things at build time - and it cannot be bargained with.

The underlying hardware is irrelevant IMHO. The masochism is very relevant.

C.

[frankvw]

Re: Not magical thinking

Whether one likes Rust or not (opinions differ on that point) I have to admit that having two or more different languages in a large and complex code set is a road highway to a massive maintenance nightmare. I've seen it before in various in-house customer projects. It's not pretty. I don't want to see that happen to Linux.

[teknopaul]

Re: Not magical thinking

A friend started a project in the place I work where the (consultants) team decided it did not matter what lang or tool añwas used as long as it worked.

10 years later we are still suffering from the fallout of that one year projects mess.

Some has been gridginly maintened at high cost. Some of the code that worked doesn't anymore and no-one knows how to fix it. So it's getting a rewrite eventually.

Bit rot is real. All code must be maintained (or money spent isolating it) continuously or it dies.

[Dan 55]

Re: Not magical thinking

If someone suggested Zig as being a second kernel language then that might gain more acceptance than Rust.

You can't even use double-linked lists with Rust's borrow checker and the Linux kernel is full of them.

[GNU SedGawk]

Re: Not magical thinking

From a Security view, i.e. a measurable outcome, I want diverse compilation, as it's the sole defence against trusting trust; so switching to a single source compiler for a "security focus" would represent a degrading of the security posture.

From a Productivity view, i.e. fuzzy feels; Rust is neither expressive enough to get out of the way, I dislike the syntax and the borrow checker adds not much to UBSan/ASan/Valgrind and testing for which bit for bit reproducible builds aid greatly How do you define safety?

Hardware is not irreverent - that's the root of the disagreement.

I want something to bit twiddle some settings or use a bit-field in a struct to meet the requirements of the problem - not to convince some bit of software that doing so is "safe" according to the "borrow checker".

Sometimes I want exactly these instructions emitted and the entire rest of the program is just scaffold to feed that loop. There's plenty of safe expressive pythonic code to express that in more C programmer friendly terms in C++, but Rust adds ? it's based on insulting professionals, who's code has millennia of hours in operation.

C++ and C get out of your way, trusting you to know what you're doing.

Rust suggests, that if the borrow checks shuts up, your perfectly constructed ode to category theory is safe. Notice "safe" not "correct", nor reasonably easy to map the running instructions back to the source code statements that generated them.

In C++ it's a little bit of a chore because of name mangling but otherwise tractable. In C it's much the same sans mangling. In Rust, please. It's a completely unsuitable problem domain for system programming or anything close to the hardware.

It's Golang for functional programmers who like curly braces - of interest to everybody other than C and C++ programmers - who already have far better tools at their disposal.

Have you seen Chrono ?

#include <chrono>

int main() {

using namespace std::chrono;

// Add durations together

duration Duration { weeks(2) + days(4) };

// Increase an existing duration

Duration += days(2);

// Doubling an existing duration

Duration *= 2;

}

What am I getting from Rust?

[containerizer]

Re: Not magical thinking

> I dislike the syntax and the borrow checker adds not much to UBSan/ASan/Valgrind

You're comparing static to dynamic analysis. Valgrind/etc won't spot anything unless you have a test cases that triggers the problem.

[GNU SedGawk]

Re: Not magical thinking

UBSan and ASan are static - Valgrind is dynamic.

The point being, tooling exists that's better than the Borrow checker's much claimed but little evidenced prowess.

[containerizer]

Re: Not magical thinking

They are static, but they are also things which are only necessary in a type-unsafe language. You don't need address checking in a language that validates address accesses at compile time. You don't need undefined behaviour checking in a language that has no undefined behaviour.

The second sentence is effectively suggesting that Rust's capabilities are not proven to work. Given the widespread adoption and the fact that Linus Torvalds thinks it is worth at least trying it in the kernel, I think the burden of proof is upon you to show that all these very clever people are wrong about Rust, not anyone else.

[Justthefacts]

Re: Not magical thinking

Rust does *not* “ validates address accesses at compile time”

All it does is validate that the address belongs to a valid object. Not that it belongs to the *correct* object, ie that state has been updated consistently, globally across multiple modules, and multiple data items that need to point to the same thing.

In other words, Rust simultaneously a) fails to identify/fix the vast majority of true latent bugs due to inconsistent state update, apart from one edge-state b) Fixes the easy validation, which everyone can do anyway, without addressing the complex validation *which you still need to be implementing, and most coders do not* c) Converts an easy-to-spot bug symptom (Crash! FixMe!) to a very subtle bug with difficult to identify symptoms d) Obfuscates the code, making the true latent bug harder to spot by inspection

Rust borrow-checker is not the answer, whatever the question is, in just the same way that owning a tourniquet is not the answer to the safety issues of axe-juggling. It protects neither your toe nor your head.

[Richard 12]

Re: Not magical thinking

Rust is literally incapable of safely replacing C++. Ever.

It's not designed to, and cannot do about 95% of what C++ is.

Unless and until Rust-a-holics stop lumping two totally different languages together, I'm going to assume they have absolutely no idea what they're blithering about.

Saying Rust could replace C++ is like suggesting removing the borrow checker from Rust would make it better. It's nonsense.

[teknopaul]

Re: Not magical thinking

Rust has unsafe for this reason, if you believe you are better than the compile time checks just mark your code unsafe so everone else knows the risk you are taking and the impact it might have on their code.

I've written quite a bit of code in many languages, rust is frustrating at the start. But in the end you find that that 99 times out of 10 rustc was right and you own code was wrong. Very occasionally you want some shared memory access that you know is safe and the compiler doesn't. Usually you find even the as you build more around this code the compile time checks we're worth it.

Particularly with test code. It's too tempting to think this a test it doesn't matter. Then when it finally breaks you find yourself debugging nasty stuff in scrappy code. That just doesn't happen in rust.

[Anonymous Coward]

Re: Not magical thinking

But in the end you find that that 99 times out of 10 rustc was right

Especially with bounds checking :-)

[Proton_badger]

Re: Not magical thinking

unsafe doesn’t turn off the borrow checker: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety:

* Dereference a raw pointer

* Call an unsafe function or method

* Access or modify a mutable static variable

* Implement an unsafe trait

* Access fields of a union

You’ll still get some degree of safety inside of an unsafe block.

[[e-mail]]

Operating systems always "unsafe"

If you can turn off the safety, then why bother ever having it on? You have to develop your own safety for an operating system, so you are better off never bothering with some poor imitation by the compiler, that you will have to turn off sometimes anyway. C is perfectly safe as long as you know what you are doing. There are some tricks to learn about how to use it safely, but there is no way to do all the things that have to be done and still have a compiler run the safety. Safety has to be hardware dependent.

[StrangerHereMyself]

Re: Operating systems always "unsafe"

I've heard this argument "you just need to be smarter" for decades. But in practice it just doesn't work that way. People are harassed by their managers to finish stuff quickly, management wants to sell stuff today so they can get their bonuses, dead-tired developers hacking something quickly into critical software and never looking at it again (HeartBleed) etc. etc. That's just life! We need additional safety nets to prevent software from becoming a liability and Rust is a life-saver in that regard.

[containerizer]

Re: Operating systems always "unsafe"

> You have to develop your own safety for an operating system,

No, you don't. That's the whole point.

> C is perfectly safe as long as you know what you are doing.

This is true of a lot of things considered dangerous for humans.

> but there is no way to do all the things that have to be done and still have a compiler run the safety

Excepting memory-mapped hardware, have you got any examples ?

> Safety has to be hardware dependent.

No it doesn't. There are many widely used memory-safe programming languages.

[Justthefacts]

Re: Not magical thinking

“Borrow checker…..But by and large, it's going to stop you doing silly things at build time”

Actually, no. In fact, it *encourages* silly things. What it does, very specifically, is ensure that any bug cannot cause a crash, and that is all it does. Well done. But it does not fix the bug, at all, that’s a bad misunderstanding.

The cause of all “Double Free / Use After Free” errors is that multiple modules or code-areas update a particular set of related data inconsistently. The correct fix is an *architecture change* to the data-structure, ensuring that it can only be accessed atomically and therefore updated consistently. But instead, the Rust borrow checker ensures Single Point of Control, using vast deep copies. This is utter *trash*. It is not a solution at all. It leaves the underlying bug (inconsistent update) completely unfixed. The only thing it ensures is that one variant of inconsistency, the one that happens to cause a memory-crash, cannot occur. But all the other bug variants within the same inconsistency remain unfixed, either actual or latent (a trivial code-change breaks something in a non-obvious way). If I malloc() a Red Thing out of sync with the Red Thing ptr, Rust has your back; but if Red Thing is just part of a static array…..Rust doesn’t have a thing to say; and yet *they are the same bug*.

It means that the developer, faced with a crash which *should* have triggered them to refactor a whole bunch of stuff, instead just hacks away for two days trying to placate the borrow-checker, and stops whenever the borrow-checker is happy. It actually maximises the number of latent logic bugs as the outcome of the development process, although the code doesn’t actually crash. If “code that doesn’t crash” is the highest goal you aspire to, then for the love of god stay away from critical stuff.

[containerizer]

Re: "it would suck"

> Software is the state of the hardware, and hardware has bugs.

Surely the idea is to have less bugs overall ?

[GNU SedGawk]

Re: "it would suck"

We want fewer bugs and less headache.

The hardware requires you to put these numbers at these locations in memory to work. It might be "buggy as fuck" or "slightly out of spec, according to the datasheet"; You still need to put the right numbers at the right address in memory for it to "work".

It doesn't matter if technically that's "wrong" it's what is required to make the expensive bit of kit perform the task.

One can argue that this is not correct, and I'd respond take it up with purchasing, we only work here.

[containerizer]

Re: "it would suck"

I appreciate the lesson in structured computer organisation, but I am still struggling with whatever your point is.

If you have two languages, one is safe, one is less safe, and you run them both on the same hardware, isn't the safe one less likely to have bugs ?

(FWIW I've been programming embedded systems for > 20 years; I've written the odd value to a memory location in my time .. )

[GNU SedGawk]

Re: "it would suck"

Safe:

The word "safe" is not an argument given a single source compiler is "unsafe"; let alone using the word "safe" as if it has some defined meaning.

Even your own definition would be useful; mine - not vulnerable to trusting trust. [1]

Numbers:

I'm saying that a language which decides that I shouldn't achieve the effect I desire, simply because [reasons] is unattractive.

You may find it easier to do pure template meta-programming in Rust - but most C++ people will tell you Less is More.

I want my code to be written so I can read it based on my intent, I don't much care about the software's opinion on the matter, it's an abrogation of your duty, either it matters so it matters, or it doesn't matter so do it in a scripting language/whatever and stop pretending to be systems language.

The point made, is that the Borrow checker if you ran it on plain C would be Useful. Given it requires throwing away a codebase / memory model / ownership semantics - it's got a high bar to clear.

With no evidence - who cares if your unreadable code is safe. What does that do for my millions of lines of code, and staff centuries of codebases?

You want me to say that a complete rewrite in a different style is a good idea because "safe" - it's supported by advocacy - likes yours, presented absent any sort of useful evidence, with the assumption you need disproving.

The compiler doesn't know more about my code than I do, sadly it only does what I tell it, not what I mean. I understand you find this language productive, I wish you success with it. For systemic reasons, it's hostile to an ecosystem built on C as the model for inter-operability.

[1] ]https://dwheeler.com/trusting-trust/

[Roo]

Re: "it would suck"

The Linux codebase doesn't exist in isolation, it's a function of the community around it. Porting the codebase to a language that is familiar to a tiny minority of that community is what would cause the damage, all those folks who aren't familiar with the new language are frozen out of the development effort - and all their domain knowledge is effectively lost with it. Thus the result would *likely* not be as good / useful to people as the original codebase (ie: it would be incomplete and it would suck balls). Ultimately it's a daft argument to have - Linus, bless him, appears to be more pragmatic.

[bazza]

Re: "it would suck"

Ultimately, it’ll go down to the developers who are available and volunteering. If Rust takes off in a big way, there won’t be any C developers left to maintain Linux anyway.

It’s also worth bearing in mind that Rusts smooth interop with C is the saving grace here. If Linux were to migrate towards Rust and away from C, there is no big rewrite. You do it bit by bit. There will be wrinkles along the way, because ultimately the interface between modules needs to stop being C and start being Rusty. This is what I think (corrections welcome) is the origin of this current argument.

Strategically, Rust has made life very complex for projects. If Rust is to take off, getting one’s own project heading in that direction good and early avoids being left behind. Jump too early, life gets difficult. Having a parallel project is hard and nuts.

For Linux in particular the hazard is that as MS, Apple, and who knows who else gradually migrated their OSes away from C and towards Rust, Linux could be the only one left suffering memory related faults. That would get annoying, eventually.

[Bogus007]

Re: "it would suck"

> Linux could be the only one left suffering memory related faults.

I think the BSDs would have a word to say. And also, I doubt highly that Theo de Raadt, the head of OpenBSD, an OS known well for its security and which is written in C, would agree upon rewriting the kernel in Rust.

[redpola]

Re: "it would suck"

If there were a strong enough case for it to be compelling he might.

The question is, how strong can we make a case? I’ve read a lot of philosophical debate on this subject recently and literally nobody has asked what problem is solved by switching to Rust. Until that’s quantified the real question of whether it’s worth it can’t be posed.

I get that “perfect” code is “better” but a bug or exploit that is never found may as well not exist.

[Roo]

Re: "it would suck"

Part of the challenge with OSes in particular is that they are built on hardware - which doesn't necessarily have a formal model, proofs and a means to verify implementations against that model. Thus the OS runs atop silicon quicksand - it can never be proven to be "correct" or "bug-free" because the hardware model it is written against is not adequate - let alone complete in 99.99% of cases. There have been efforts to plug this hole - eg: RSRE's VIPER microprocessor, but as far as I know these methods haven't been applied comprehensively to common or garden x86 type gear.

[MacroRodent]

Re: "it would suck"

> porting/converting millions of lines of kernel code is going to take some time

Some time, as in, several years by a competent team, if the goal is Linux as it is now, and not some Linux 0.9. Essentially a full rewrite of the Linux kernel.

[meski-oz]

Re: "it would suck"

It's going to be a rewrite of a moving target, and I don't imagine merging fixes from c to rust and vice versa will be pleasant, so what do you think will happen?

[dinsdale54]

Re: "it would suck"

A company I used to work for rewrote/ported its OS from a hand-rolled kernel to BSD. There was over 15 years of development work in the original and it took over 10 years before they had feature parity in the new one. It was a fair bit smaller than Linux.

As you say it's a HUGE amount of work. If you are relying on a small number of people, some working in their spare time to do this work you had better make a pretty good case for doing it.

[Munchausen's proxy]

Re: "it would suck"

" It might suck in that porting/converting millions of lines of kernel code is going to take some time, and in that time, the new kernel will be incomplete."

Harumph. <old fart mode=on> Maybe someone should have thought of that before they accreted a 'kernel' millions of lines long.

[[e-mail]]

Rust is bad

There is no way to make any operating system safe by imposing strict compile time limitations. And I think it is impossible for Rust to do what any operating system needs to be able to do.

There are times you need to do things like execute hardware jump tables. Anyone who thinks you can make things like that safe, has never written an operating system.

As far as the risks C presents, it is easily fixed by setting all pointers to null ahead of time, checking for null pointers before de-referencing, and tracking all dynamic allocations.

It is trivial to make C the perfect operating system language. And there is no way to make it better.

Nor it is trivial to mix languages. It is bad enough ensuring you get the right compiler version for 1 language, much less more than one.

[StrangerHereMyself]

Re: Rust is bad

Your arguments have been rug-pulled by RedoxOS and others.

[redpola]

Re: Rust is bad

“ It is trivial to make C the perfect operating system language. And there is no way to make it better”

And you left a deliberate error in that to see if we’d spot it? Or to prove how fallible humans are?

[teknopaul]

Re: "it would suck"

Rust can't react to out of memory errors. Last time I checked. I always thought that made it incompatible with kernel work.

when you hit oome I rsut code you have to kill the process. Can't even panic. I don't see how that would work in kernel code.

killing a driver for a fitbit is one thing. But other drivers would need to gracefully handle oome.

[StrangerHereMyself]

Re: "it would suck"

You can just handle the condition as you would with C-code. You can't need to panic (literally and figuratively).

[klh]

Re: "it would suck"

Kernel afaik uses no_std, so it doesn't need to abort on OOM

[Lee D]

Re: "it would suck"

Okay, here's the issue.

Rust is, effectively, C.

Yes, it has safeguards around certain portions... but the second you have to do certain things (address hardware, assume the structure of an arbitrary data blob coming from a device, etc.) then you have to have that in an unsafe wrapper.

An OS, device drivers, and especially things like DMA - they have to do those "unsafe" kinds of things. So you gain nothing.

Sure it protects against some string abuse here and a small overflow there, and things like that. Undoubtedly. But where it actually matters.. you have to put things in an unsafe block which, by definition, can destroy any assertions made about that code AND the surrounding code (by way of unsafe code potentially modifying believed-safe code nearby in memory).

So some people see it as nothing more than some extra steps that, to be honest, you can remove the appearance of by design and code-styling (e.g. "let's just not play clever tricks with printf", and so on). Which the kernel does a lot of, especially in deep kernel code (there's a kernel printf, for example).

All rewriting the kernel would do is take decades of effort, put off a lot of existing coders (and it's hard to find people willing to maintain things like DMA across entire architectures!), and actually gain you so little that it's not worth it. It would also not be any more secure at all, not in the grand scheme of things. You're basically just putting a worthless cordon around certain parts of the code saying "Here be dragons" but unfortunately, those dragons are a necessary and vital component of modern PC architecture (until we get devices speaking well-defined structured data for all communications and remove DIRECT MEMORY ACCESS so they can't play games with said structures... which hasn't yet happened and would kill performance if it did).

Rust is great for new applications, etc. but I've never seen a significant piece of Rust without at least one unsafe block. And in kernels, it's just dumb.

It's basically just C, but with a large cordon around anything dangerous. It's like wrapping a entire town in cotton wool, but then having to put out the traffic cones around the same sinkholes that we already know are deadly, expanding, move around, appear out of nowhere, and are undermining the "safe" cotton-wool-wrapped people all the time.

[JoeCool]

Re: "it would suck"

"Ada fan fiction" as a comp lang student of the 80s, that kills.

[swm]

Re: "it would suck"

Where is the rust standard? Is it just what the compiler does?

[Justthefacts]

Re: "it would suck"

Linux kernel is pretty solid as it is, the number of bugs you would introduce by re-factoring to a new language is *vastly* more than you could possibly expect to fix. I would say 10x, but 100x would not surprise me at all. Memory-safety bugs really are only a modest percentage of all latent bugs. Significant maybe, but far from the majority.

[hittitezombie]

Knew it.

Embrace, Extend, Estinguish.

[druck]

Say what?

The Linux kernel added support for Rust code on October 3, 2022, shortly after Microsoft Azure CTO Mark Russinovich argued that new programming projects should be written in Rust rather than C or C++.

Since when has the utterings of a Microsoft lackey had any bearing on Linux kernel development?

[jake]

Re: Say what?

"Since when has the utterings of a Microsoft lackey had any bearing on the Linux kernel's overall development?"

FTFY

The answer is never.

_{Need I point out to the readers of this august rag that Microsoft has been contributing to the kernel for years? And not in Rust, either ...}

[m4r35n357]

Re: Say what?

Well you obviously missed all the fun on the kernel mailing list with systemd . . .

[diodesign]

Re: Say what?

We're not saying they are necessarily connected. If they were connected, we would have said so. We're saying that around the time the Linux kernel project was opening the door to Rust, the Azure CTO was remarking how good the language is for security and reliability.

From that you can infer Rust was at the time getting more recognition and support.

C.

[druck]

Re: Say what?

I think we can infer Microsoft was trying to sell something, what I'm not sure.

[kennethrc]

This is the scariest part of all this, IMO

> Hector Martin, project lead of Ashai Linux, shared his belief that Hellwig's remarks constitute a Code of Conduct violation

Shameful. Kernel devs calling for disciplinary action 'cause they don't like someone's take on a technical subject?! If you read the thread quoted (https://lore.kernel.org/lkml/[e-mail]/) there's no cursing or anything but Christian's dissenting opinion (and his reasons for having it), but nah, let's just cancel-culture a sentiment Hector doesn't like.

[doublelayer]

Re: This is the scariest part of all this, IMO

I thought the same thing when I read that sentence, and to some extent I still think so. However, thinking more about the message, it's an announcement that he plans to sabotage someone else's work, not because it has a technical flaw, but because he doesn't like it. If I was a maintainer and someone submitted a patch for a piece of hardware, and I tried to prevent it being merged because I don't use that hardware and I don't want to worry if my future changes might break it, it would not be productive. Linux works as a project because developers agree to work in such a way that they don't break other parts, considering compatibility with parts they haven't written. The Rust developers aren't telling the maintainers that they must also write their contributions in Rust, but they are asking for the same compatibility that developers of other components are expected to provide.

Code of conduct seems like the wrong way to categorize this, but that doesn't mean that it is a completely justifiable approach to development.

[janusng]

Re: This is the scariest part of all this, IMO

You must be new here.

Linus Torvalds has resisted C++ code in kernel for decades.

[GNU SedGawk]

Re: This is the scariest part of all this, IMO

He's got good reason.

You can use C++ and make drivers just fine - e.g. OSX drivers are in C++. But once you can't use the STL, don't want to use Templates, need more fine grained control over layout. Can't use exceptions, want more predictable stack usage etc.

Most of the useful stuff in a C++ runtime is not really suitable in the kernel. So once you've stripped it down, you end up with C and a load of additional rules to follow. So just use C.

[Richard 12]

Re: This is the scariest part of all this, IMO

Not really.

C++ is suited to writing a kernel, and in fact some have been. There are a few features of the STL to avoid in some circumstances, but those are basically the same as with C - the kernel is supposed to provide their implementation, so you have to implement them...

The reason for resistance to C++ in the Linux kernel is exactly the same as resistance to any other languages - the moment you have multiple languages, maintenance becomes a lot more difficult.

Drivers, including kernel-mode ones can and indeed should be written in other languages. Rust, Zig, and C++ are all good options, there are many more. Pick one you know well.

[[e-mail]]

C++ can't so an OS

If you write the OS in C++, then how does the OS do a 'new' dynamic allocation to itself? You can do a malloc(), but not a 'new'. In fact, there is no virtual function table or anything close to what C++ entails.

[GNU SedGawk]

Re: C++ can't so an OS

Linux and C have VTables Linux is full of them e.g. https://tldp.org/LDP/lkmpg/2.4/html/c577.htm

Memory is easy

Placement New and a you need a custom allocator http://en.cppreference.com/w/cpp/concept/Allocator

// construction

template <class U, class... Args>

void construct(U* placement, Args && ...args)

{

// explicitly use default placement operator to construct into the memory,

// we support all overloaded constructers

::new((void *)placement) U(args...);

}

Arena Allocator

class Arena {

...

// these obtain memory from kmalloc

// 1) called as new Arena

static void* operator new(size_t nbytes) throw();

// 2) ? - returns memory unmodified as everyone seems too

static void* operator new(size_t nbytes, void* locality_hint) throw();

// 3) called as new Arena[count]

static void* operator new[](size_t count, size_t nbytes) throw();

..

}

[Richard 12]

Re: C++ can't so an OS

C kernels have to implement malloc too!

It's not a single CPU instruction. It's a large lump of code that somebody wrote.

In fact most OS and even toolchains have quite a few different allocators, with different use cases and tradeoffs - it's literally how valgrind and some other tools work.

C++ "new" explicitly supports writing your own allocators. You can have as many as you like.

Most userspace code doesn't bother because the default one from the toolchain is usually good enough.

[An_Old_Dog]

Opposition != Sabotage

The key here is the phrase, "I will do everything I can do to stop this." Some people could (and have) extrapolate(d) this to mean "sabotage"; others could (and have) extrapolate(d) this to mean, "by all fair means, oppose."

Software maintainability is a technical issue.

[JoeCool]

Re: Opposition != Sabotage

Well said. I read the linked email, and the opposition seems to be well founded in real concerns and a reasoned line of thinking. And I applaud transaparency; you know exactly what that maintainer is thinking. "Cancer" is not an unfair analogy, but to imagine that his comments include "sabotage" is ridiculous .

In that email the Rust dev is working hard to dodge the hard questions; it's a pretty irresponsible attitude, and another red flag because the people that you bring into the community also matter.

So many devs seem to have bought the lie of "move fast and beak things".

[containerizer]

Re: This is the scariest part of all this, IMO

> it's an announcement that he plans to sabotage someone else's work, not because it has a technical flaw, but because he doesn't like it.

This is a mischaracterisation of what Hellwig said.

He didn't say he didn't like Rust. He said that maintaining two codebases in the same kernel would be too difficult and would threaten the future of the kernel.

I don't think he should be disciplined for saying this.

[Missing Semicolon]

Re: This is the scariest part of all this, IMO

Reading the comments in the thread, there definitely seems to be a case of "I enable the Rust components, I change some Code, it stops building. If I disable the Rust build, it works again". That sounds like there needs to be more work on the shim layers to be less fragile.

I can see that one might get unhappy if you say "this breaks things" and you get the response "our code must go in, and you must help maintain it!"

[sarusa]

Old man yells at cloud

Darn y'all millenials with yer 'mammary safety' and 'borrow checkin'. Why back in my day, we just backed up right over the edge of a signed char array we was using to hold a complex struchoor, and it didn't hurt us none. Wall sometimes thar was a segfault, and if the party were REALLY goin' on, a kernel fault, but joo know what? We LIKED it thet way. You damn kids with your 'seatbelts' and 'airbags' and 'mebbe we shouldn't just trust devs to catch all possible mammary axis vi-oh-lay-shuns because obviously most don't even usually try.' WELL BOO HOO, buttercup. We've whipped this thang into pretty plumb good shape, just a few scuffs from when it went off the road (we may have bin drinkin') and every now 'n' than we bolt somethin' to the side and whoops... kernel fault! And we go 'tsk tsk shudder coulder woulder caught thet!' But then ah goes back to mah desk, ah does, and ah press mah fingers to mah lips, smirk, and go 'tee hee hee hee hee.' Ahhh, good times, good times.

[Anonymous Coward]

Yes, definitely an interesting thread read...

Especially https://lore.kernel.org/lkml/[e-mail]/

I can see why a maintainer may not want a shim of the C API that he is currently responsible for in another language, as it adds a reverse dependency that he will need to consider and possibly maintain when adding or changing his API.

Maybe a rule change to explicitly state that a reverse dependency is not his responsibility but the sole responsibility of the project adding that dependency.

IMHO Hector needs to try to be a bit more understanding and constructive.

[Dan 55]

It seems there's some drama going on, Marcan has deleted his Mastodon account.

[Anonymous Coward]

Rust is absolutely garbage syntax wise, not to mention the unsafe libraries. The syntax makes doing code reviews horrible. I think it would be the beginning of the end if linux kernel incorporates rust garbage in it. It is amazing how people have endorsed rust without much history and studies that show it is worth it. It takes years to find issues with a new language, and industry and proponents should wait, study the pros and cons after few new large projects have been done, and then open their mouths.

[Anonymous Coward]

Not even going to risk some angle brackets here

O'nce y'ou ::start::using all().the().features() | it does begin | to_look()! like line noise sometimes

[skalamanga]

If you find Rust syntax hard to understand, that's a you problem. Calling it garbage because you have no idea how to read it just shows off your own limitations.

[frankvw]

"If you find Rust syntax hard to understand, that's a you problem."

Absolutely. But if there are too many developers who have that "you" problem then it becomes a language problem. Also, Rust may be the language-du-jour now, but Linx is a very long-term project. C has been around for more half a century. Rust still has to prove it can provide that sort of continuity.

While Rust may have some very good features that shouldn't be discarded simply because of conservative attitudes, I can understand one's reluctance to Rust-ify the Linux kernel or similar projects where continuity, maintainability and the use of proven technology are prime requirements.

The fact that C developers vastly outnumber Rust developers should also be taken into consideration. Yes, Rust is mature (it reached V1.0 about 10 years ago) but so is Java, and that will (for good and sufficient reason!) never be considered a candidate for further Linux kernel development. So Rust will have to come with advantages that are so major that they significantly outweigh the disadvantages of having to mantain cross-language code bases that contain relatively new languages that many are not yet familiar with and that may not even last.

[Anonymous Coward]

.

... reluctance to Rust-ify the Linux kernel or similar projects where continuity, maintainability and the use of proven technology are prime requirements.

Basic common sense.

+1

.

[Bebu sa Ware]

Language wars so last century...

If you find Rust syntax hard to understand,

That is a question that could be answered. Does the syntax and semantics of Rust place an excessive cognitive load on the coder or reader compared with other languages?

that's a you problem.

Only in simplistic sense as any language that is "too hard" will wither without new recruits.

Calling it garbage because you have no idea how to read it

A fair enough but amusing in that Rust doesn't use garbage collection but shouldn't in principle produce garbage.

just shows off your own limitations

Anyone who admits having no limitations immediately displays at least one. ;)

Even though for me looking at Rust code ranks with reviewing a page of Snobol IV, I am encouraged by Rust specific projects like RedoxOS putting early runs on the board. As they say nothing succeeds like success.

[An_Old_Dog]

Re: Language wars so last century...

Hey! I liked SNOBOL. It's like BASIC, but for string processing.

[Proton_badger]

Re: Language wars so last century...

> I am encouraged by Rust specific projects like RedoxOS putting early runs on the board. As they say nothing succeeds like success.

Indeed. The AGx Linux graphics driver is a resounding success. It's a big driver with complex thread and memory management but was written in record time and has never had any memory errors in production, this is unprecedented in several ways. It is Vulkan 1.3 conformant.

If nothing else it has proven beyond any doubt that not only are Rust drivers viable, they bring good things to the table.

Is Rust hard to understand/read? I don't know, I've C++ for decades and I find Rust prettier than modern C++, though more syntax and concepts to learn than C. But no matter the language, kernel development is hard, a benefit of Rust could also be that with the compiler doing more the developers has fewer balls to keep in the air. I certainly enjoy it, I've spent too much of my career hunting obscure memory issues in people's code.

[m4r35n357]

Typical "macho" dev response. The language should be as easy to use as possible so that developers can concentrate on the problem domain (the important stuff).

[GNU Enjoyer]

The beginning of the end of Linux started once it became proprietary software again in 1996

and the license to the "other parts" was stated to be GPLv2-only in 2000.

Much of Linux has rotted since then, although GNU Linux-libre has been able to successful exorcise the proprietary rot from each version so far.

[skalamanga]

No Microsoft "engineers" in the rust kernel, please.

[Doctor Syntax]

Microsoft engineers have contributed to the kernel for years. It's Microsoft engineers in init that are the problem.

[Sceptic Tank]

Seing some bad oxidation in the kernel, there

So instead of converting C to Rust, why don't you convert Rust to C? That way you can code your little program in a safe environment, make sure you're not hurting the little pointers, and send your contribution off as generated C. Let me go make room in the trophy cabinet for the 2025 Turing award.

[Anonymous Coward]

There is an interesting point raised in the mailing list. While the Rust bindings are the responsibility of the Rust team, changes to the C API could break the Rust bindings. While it would be on the Rust team to fix, the “you break it, you fix it” policy is broken and getting a change merged is going to depend on both the subsystem maintainer and the Rust team.

[Sam Liddicott]

Can have it both ways

Hellwig doesn't want the code in his repo because he doesn't want to maintain it.

He also doesn't want it outside of his repo where somebody else will maintain it.

He says it makes kernel code harder to maintain.

The whole reason people are using rust in the kernel is because it makes also makes some kernel code easier to maintain.

If Linus doesn't move for acceptance then we will have an egcs situation - a separate kernel tree will be maintained and we will see which one the distros take.

Linus is smart enough to see that, is also smart enough to see the technical benefits.

Hellwig needs to think less about what his preferences and more about where the kernel is going to be in 10 years regardless of his position.

There are going to be rust kernels. He can influence whether or not they are called Linux.

But at least one of them will be based on Linux.

[frankvw]

Re: Can have it both ways

"Hellwig needs to think less about what his preferences and more about where the kernel is going to be in 10 years regardless of his position."

It's the concern about where the kernel is going to bein 10 years that's fueling the concerns about introducing Rust code into it right now.

[containerizer]

Re: Can have it both ways

>The whole reason people are using rust in the kernel is because it makes also makes some kernel code easier to maintain.

It makes some kernel code easier to maintain for some people, and makes life harder for others. It means that instead of having to learn one language, kernel devs have to learn two, because now any breaking changes they make could effect the Rust layer as well as the C codebase.

[mpi]

Re: Can have it both ways

> Hellwig doesn't want the code in his repo because he doesn't want to maintain it.

Which is completely understandable, because why should C focused maintainers be forced to maintain code in another language just because someone else likes that language better than C?

> He also doesn't want it outside of his repo where somebody else will maintain it.

Problem is, that code depends on his code. It's an abstraction layer over his code. So, in the future, every time he needs to change something, he HAS TO deal with this code, whether or not it is maintained by him, because that code will expect certain things, and other things will depend on that code, etc., and so forth.

The kernel isn't like some backend where I can just go to client maintainers and tell them "this is the API, deal with it". And even as a backend developer, I have had MANY conversations where I suddenly had to do/not-do something because something changed in some client someone else developed. And suddenly, I was out of my go-codebase, and had to read / understand / respect something someone else had written in godknowswhat-lang.

And I vividly remember that I really really really did not like doing that.

Having this situation in the kernel, where things are far more connected and interdependent, is probably orders of magnitude worse.

[Zolko]

Re: Can have it both ways

The kernel isn't like some backend where I can just go to client maintainers and tell them "this is the API, deal with it"

actually, that's the real subject here : if Linux were a micro-kernel – or even a hybrid mini-kernel – then the APIs and even ABIs would be stable and documented, and one could write drivers in any language. But since it's a monolithic kernel, everything is in one huge blob of source-code, therefore the interfaces are moving and thus any other language is excluded. By design.

If the refusal of Rust in Linux makes Rust people write a new micro-kernel with userspace drivers, I'm all for it. Heck, this is the likely outcome anyway. Although I doubt it will be written in Rust

[[e-mail]]

Can't do an OS in anything but C

There is no way to do an OS in Rust. The hardware forces the use of things like jump tables that Rust does not allow. You can't rely on safety code to catch things when you are the OS.

[steelpillow]

I'll get my coat

Obviously should design a best-of-breed kernel code language, and migrate everything across to that.

You could call it - oh, I dunno ... Crust?

Some kernel developers are pretty crusty already.

[swm]

Re: I'll get my coat

LISP is older than almost all other languages and is memory safe. A modern LISP compiler can produce code just a fast as C. Modern GCs are very fast and can do hard real time. Memory allocation is much faster than malloc. etc. Yes, operating systems have been written in lisp, smalltalk etc.

[jake]

Re: I'll get my coat

I hacked on a LISP machine for nearly a year when I was at SAIL, but finally I saw the futility and went back to hacking BSD on VAX. (Actually, a small cluster of vaxen, which DEC helpfully donated.)

The only place I ever used the LISP experience in the wild was with the bastardized AutoLISP, starting about 10 years later and continuing to this day.

[Will Godfrey]

Attitude

In my (very limited) exposure to Rusticans I find them almost all of an arrogant nature. That sets off warning alarms in my mind. I wouldn't want to have to deal with them.

[Anonymous Coward]

Re: Attitude

Sounds like my experience with *insert language here*

[Daniel Pfeiffer]

Re: Attitude

In my more extensive exposure to Rustaceans I find quite the opposite. Obviously you caveat your comment as anecdotal, so there’s no arguing with that. But if you’re looking for counter evidence, look no further than the Rust for Linux guys. They are humbly going out of their way to make it clear that they are shouldering the interop burden. They only ask for clear APIs, so that they know what to deal with.

[Zolko]

Re: Attitude

Rust for Linux guys. They are humbly ... They only ask for clear APIs

I hope you realise that this doesn't make sense : Linus has always said that clear (stable) APIs won't ever exist. So how could people "humbly" ask for something that has been explicitly excluded before ? That's the very definition of "arrogant", to the point of "harassment".

[mpi]

Re: Attitude

> They only ask for clear APIs, so that they know what to deal with.

That places part of the "interop burden" on the existing maintainers though.

Those APIs have to be written, and maintained, in C. By people who then, with the kernel being a monolith, and all things being tremendously connected to one another, have to read, respect and understand issues that arise in Rust-Codebases, which they didn't write, and may not want-to/have-time-to deal with, whenever they have to touch their own code.

This is already a difficult enough task when everything is in one language.

[Anonymous Coward]

Re: Attitude

Yes, been there when java & javascript were the 'new hotness'. Suddenly people were calling you names if you didn't immediately rewrite everything in them. I saw someone advocating for rewriting 'ls' in rust the other day, for.. reasons..

Give it time and it'll settle down, rust will find its niche or be replaced by something else.

[ChrisElvidge]

A better way to get Rust into the kernel perhaps would be to start from scratch - rewrite the whole kernel in Rust, then prove it is as good as or better than as the current kernel.

Users, or distro makers, could then decide whether to use the old kernel (C) or the new kernel (Rust).

[Anonymous Coward]

"Just rewrite the entire Linux kernel in Rust, then we'll look at your patch" is what you're saying here

[Zolko]

PoC

No, he's saying that they should write a proof-of-concept kernel, before being too mouthy about their pet language. Something with limited scope, but enough to show that it can work.

[StrangerHereMyself]

Or all developers could just move over to RedoxOS or MINIX.

[ltlnx]

Is it only me or…

Did Hector delete their Mastodon account?

[John Lilburne]

Hrumph RUGRATS. One saw it all the time a 'new shiny thing' would come along and coders wanted to adopt it. A fight would ensue to keep it out of the codebase which was eventually lost. Within six months they'd moved on to another 'new shiny thing' the old 'thing' abandoned and disowned. Someone coming to fix or extend some code now has to work with understand the 'old shiny thing'.

[GNU Enjoyer]

What is Linux if not a kernel?

If you want to stress that Linux is only a kernel, please write; "the kernel, Linux" or "Linux, the kernel" and please do confuse people by implying that Linux is more than a kernel by writing; "the Linux kernel".

>open source uber-project

Sorry to break it to you all, but Linux, the "poster child of open source" isn't even completely source available, as it contains proprietary software without source code!

[m4r35n357]

Re: What is Linux if not a kernel?

You might disagree with the OP's sentiments, but both those statements are correct.

[nvmd]

The fork in the road?

LoL This is it. We all knew this was coming. Time to decide what happens to the pressure cooker. If Linus says yes to Rust, it'll set precedent and the "rewrite the kernel in Rust stops being a slippery slope. If he says no, the seething Rust virgins will lose momentum and might give up dealing with core subsystems or they might fork the kernel, which I would rather have than the hybrid bs.

[m4r35n357]

Re: The fork in the road?

Yep. Rusticans, fork the kernel, weave your magic, and come back when you have something good (a POC).

[nijam]

> "For the sake of security and reliability, the industry should declare those languages as deprecated," Russinovich said.

"For the sake of security and reliability, the industry should declare Microsoft as deprecated," I said.

[volsano]

Standards

Does Rust have an internationally recognised Standard definition?

Does the standarising authority guarantee that new features in later revisions of the standard will be fully backward compatible with existisng code (bugs included)?

If not, then the Linux project many be opening a decades-long can of worms regarding versioning and interoperability of Rust code bases.

Most prudent approach: at least wait until Rust has stabilised and matured before relying on it. For now, at best, use it for app-level work and demonstrations.

[Richard 12]

Re: Standards

Two implementations would be good.

Right now there's slightly less than one.

[An_Old_Dog]

Re: Standards

I'm unwilling to write in a computer language whose revisions break my old programs. There's enough pointless change in the computer world without the "it would be so cool to do this!"-neophiles radically-changing a programming language's features and how it works.

[captain veg]

forget coding language

I grok C pretty well, Rust much less, but even if I were so minded I could never agree to abide by the Linux Kernel Coding Style. Just ugh!

-A.

[jake]

Re: forget coding language

Then it's a good thing nobody's asking you to do so, isn't it?

During the meanwhile, it's quite refreshing for those of us who do/are to wake up in the morning and dive in without having to navigate through the wretched code of hundreds of kiddies who each think they have a better idea of what "readable" means.

[captain veg]

Re: forget coding language

If you like,

For what it's worth my main problems with kernel style are it's endorsement of goto, which is evil and unnecessary in anyone's language, and K&R bracket placement, which is simply perverse.

-A.

[Dan 55]

Re: forget coding language

Allman all the way.

Although I will begrudgingly use other styles if the code is already written in another style, but they're still wrong.

[captain veg]

Re: forget coding language

When I lectured C programming I gave all my examples in Allman style, even though I didn't know then that's what it's called.

My students submitted assignments in what I can only call random style. By which I mean that indentation and brace placement seemed to follow no obvious pattern. Almost like Python. And this was because they were pretty much all Cobol programmers looking for new contracts.

I still don't get the defenders of goto. The mechanics of setjmp and longjmp are, however, a marvel. But never to be used.

-A.

[jake]

Re: forget coding language

"I still don't get the defenders of goto."

https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/

[Dan 55]

Re: forget coding language

> > No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a frigging clue.

> I thought Edsger Dijkstra coined the "gotos are evil" bit in his structured programming push?

Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So these days I can only rant about Niklaus Wirth, who took the "structured programming" thing and enforced it in his languages (Pascal and Modula-2), and thus forced his evil on untold generations of poor CS students who had to learn langauges that weren't actually useful for real work.

[Anonymous Coward]

Re: forget coding language

Unfortunately, Niklaus died last year - sad that we're losing the folks that created the languages we're using. Agreed, I've not used Modula-2 since leaving Uni but I don't regret using it for a few projects back in the '90s and I've had occasion to work with languages that some would deem much worse since then :-)

[scobiej]

You want a kernel in rust, write one. Leave this one alone.

[StrangerHereMyself]

Agreed

I do believe he's right in saying that the Rust code needs to adhere to C API standards and not the other way around. There's no issue if the Rust code exposes a C binary API and does whatever it wants in its own code, as long as it plays nicely with the kernel.

[Anonymous Coward]

Re: Agreed

The problem is those rust bits have to call the C code back in return, and those entrypoints aren't fixed in stone.

Currently, if a maintainer changes an API in the kernel, it's on them to change all the calls to it, so that they don't break stuff. This is generally easy enough, it's all C.

Put rust in the mix and the C maintainers now need to be rust experts to avoid breaking the rust parts when the C parts change..which creates a maintainability mess.. either you can't change anything, which stagnates the kernel, or you have to constantly coordinate with the rust maintainers before putting in patches, which slows down development.

[Artem S Tashkinov]

"Hector Martin, project lead of Ashai Linux, shared his belief that Hellwig's remarks constitute a Code of Conduct violation but doubts any disciplinary action would be taken."

Only the authoritarian regimes have censorship.

Here, in our exalted West, we have our nice and soft CANCEL culture.

[Anonymous Coward]

Why not fork

One thing on this RUST thing not clear for me that if they believe so much. Why not fork the Linux kernel and let anyone join their project who believe.

Better even. Why not rewrite from zero?

Why is this important that everyone else should abandon the main project?

Don't like Linux. There is BSD. Don't like Unix there is Windows, Haiku.

Why should be there a world where there is only Rust Linux?

Make another Rust Linux, BSD, Windows, Haiku. Let the users decide they want C Linux or Rust Linux.

[Philo T Farnsworth]

Rusnix, anyone?

Maybe there's some young Finn out there doing that right now. . .

We just need another Andy Tannenbaum to annoy him sufficiently.

[JasonT]

Conflating Utility in Kernel and OS?

I'm not a Kernel developer. I've written C code back in the day to communicate with serial and parallel ports, and I've recently dabbled with Rust on a user-facing application. So my opinion is admittedly poorly informed.

There are things that are awesome about Rust. Pattern-matching enums, and implementations like Option and Result are great. Using serde to handle JSON is awesome, I don't have to "guess" whether something is a string, a number, etc. Unlike C#, I don't have to worry about a library I'm using really does have nulls properly. Very good things all around, excluding ambiguity around async handling (to tokio or not to tokio...) and error handling (why do we even need thiserror, anyhow, etc.?)

But... in a kernel universe where I imagine you are communicating directly with registers, swapping and paging memory, triggering and responding to interrupts (if that's even a thing anymore), it seems like you'd have to be plugging in "unsafe" in enough places that you are short-circuiting a lot of of the safety that Rust is trying to provide.

Rust seems like a very good fit for the OS, stuff can be built and deployed independently, and where you are directly communicating with user space and getting thrown "who knows what?" Rust's micro-management of typing, ownership, etc. seems very well suited to this corner of the universe. Maybe efforts should be focused on leveraging Rust in the OS, and further refining the language before trying to use it in the kernel.

[JLV]

Anyone else think the "Code of Conduct" shit is a tad over the top?

This controversy is an interesting technical and organizational tug of war, and despite leaning towards the "Rust-good" side of things myself, calling Rust a cancer, while histrionic and alarmist, really doesn't qualify as harassment of anyone.

[CyHarsh]

Indeed.

The problem with the gratuitous adoption of “codes of conduct” is that it opens to door to a special category of soapbox opera stars who derail technical discussions with perceived offences.

[CyHarsh]

“Code of conduct” cancer

I note with amusement the reference to “cancer” as a code of conduct violation. Snowflakes, this generation.

Anyone who hides their incompetence behind such silly rules deserves to be kicked out of the dev team.

[Anonymous Coward]

What's the obsession with "hardware jump tables" as the reason rust can't be used in the kernel?

Could someone share some docs or a link to a real world example of this? The frequency of the argument makes me think 1/2 the kernel must be implemented in hardware jump tables :s

[Richard 12]

Rather a lot of it is

To call a function, the application needs to know the address of that function.

In a statically linked application, all the function addresses are known when building, so the linker can go through and fill them all out - job done.

That doesn't work for dynamic libraries.

A dynamic library gets loaded where there's space. That probably isn't going to be the same place every time! (And things like ASLR deliberately change it)

So a jump table is built to bounce the calls to whereever each function actually ended up. (Sometimes literally called a trampoline)

Most drivers are dynamically linked to the kernel, and user-mode application code (usually) cannot even see the memory where kernel functions really live - they get access to a trampoline, but not the code.

Kernels also use jump tables to handle hardware interrupts and exceptions - eg to context switch to a new thread or process, load something into RAM, live-patch an application, signal a warning or error, kill a misbehaving application and recover its resources, and many other things.

So there's quite a lot of jump tables built at runtime.

[Heya]

Re: Rather a lot of it is

Right... What you're describing there would be "software jump tables". They're not implemented in hardware - they're software.

Rust's match statement is compiled to a jump table by LLVM when a jump table would be the most efficient implementation.

So... What is it you can't do with rust?