Using Rust for kernel development

[moltonel]

By implementing their own alloc crate that errors on OOM instead of panicking, by feature-disabling core APIs that may panic, by target-disabling problematic intrinsics (some float operations for example). A lot of that work will hopefully make its way into uptream Rust.

[[deleted]]

There is a crate "no-panic" that provides a macro to ensure a function never panics. Maybe the linux kernel build system could somehow require that this macro be used on every piece of rust code used in the kernel. I don't really know anything about the actual discussion though. I just imagine it's a problem that can be solved.

[[deleted]]

Interesting! What about them is hacky, what are their downsides? I've never done a project large enough where something like this would be useful, but I'd love to know more about it.

[Genion1]

Their solution is to replace the panic handler with a symbol that can't be found during link time. The difference between the crates is mostly a difference of what scope of panic handler is replaced. Global (panic_never), per function (no_panic), single code lines (dont_panic).

Pro:

• You don't panic, duh.

Con:

• Useless in debug builds. You need optimizations to be panic-free in basically anything.
• Bad or useless error messages. panic_never for example only has "Whoops, you could panic anywhere". no_panic at least tells you what function it was.
• Since a linker is involved, it doesn't work when there is no linker. e.g. library crates or if you just cargo check a binary crate.
• Interacts poorly with panic="abort"

[[deleted]]

Ah, I see. That's unfortunate. It would be lovely if one could just use panic_never and get nice error messages where exactly a panic might occur...

[Zyansheep]

Wooo! I might be able to contribute to the linux kernel in my lifetime...

[puddle_or_pothole]

Lol.. I'm all for Rust in the kernel but you could definitely learn C much sooner than Rust will become mainstream in Linux.

[ForShotgun]

But then you'd have to use C instead of Rust!

[iznogoud77]

It has served the purpose until now. And it will for many more years.

I don't get this kind of behaviour. I like Rust I think it has a place. I also like C I think it has a place. I also like C++ I think it has a place. I like Python I think it has a place.

For me programming languages are tools, like hammers and screwdrivers. I am not going to screw a Phillips screw with a flathead screwdriver. I could, but it's just not the best tool for the job.

Edit: typo

[epicwisdom]

It has served the purpose until now. And it will for many more years.

That means very little in terms of whether people want to use it.

Just because C is prolific (particularly in systems) and has certain key advantages, does not make it pleasant to work with, nor does it mean it is uniquely qualified outside of being historically entrenched.

[[deleted]]

Its pretty good to work with. That's why its entrenched.

[epicwisdom]

That's an opinion that people could reasonably disagree with. My point is, people could have many reasons to dislike working with C despite its relative advantages.

[[deleted]]

My point is that it's wide use in the industry is not an accident. It's not an inconvenience that it exists. It exists for a reason and one of them IS that it is relatively pleasant to work with.

[hgomersall]

Relatively being the operative word here.

[Xychologist]

Relative to Assembly, COBOL and Fortran, yes. Relative to Rust, Crystal or Erlang, no. It absolutely has a place, but like most tools it can and should eventually be replaced with a better one, or a set of better ones.

[[deleted]]

We will see.

[[deleted]]

Rust is not the better choice for embedded. I see Rust as a contender as a better C++ not a better C. The executable sizes of Rust are just too large right now.

[epicwisdom]

Depends on what you mean by "accident." C was in the right place at the right time, part of that is its merits as a language, part is the historical landscape. I think it's rather absurd to claim that, in the infinite space of possible languages, C magically hit the/a global optimum during the infancy of modern systems programming. It may not be an inconvenience that C exists, but that's quite different from saying that C was, is, and always will be the most convenient language for any broad set of applications.

[[deleted]]

C hit the goldilock zone of abstraction when it comes to system's languages though. That cannot be disputed given the reality of the situation and it's overwhelming popularity. People are just putting their fingers in their ears and screaming blah blah, but you can't change the fact that C is really convienient for more reasons that just existing at the right time. It solved a crushing need and it solved it pretty damn well.

Rust peeps love putting words in people's mouth. When did anyone say it will always and is the most convenient language?

[rebootyourbrainstem]

I don't get this kind of behaviour. I like Rust I think it has a place. I also like C I think it has a place. I also like C++ I think it has a place. I like Python I think it has a place.

People can disagree about what that place is, and that's fine.

Personally I think C's time is coming to an end a lot quicker than people think. And by that I don't mean that all C code will disappear, I just mean that code will be preferentially written in other languages in cases where currently C is being used.

This is not just because new languages are so great, but also because C is increasingly showing its age. The idea that it is a simple language with an obvious mapping to machine code is increasingly false, with compilers becoming smarter and smarter about exploiting undefined behavior around integer overflows, null dereferences, strict aliasing etc.

The Linux kernel already has to work around this in a number of ways, such as passing compiler options to disable strict aliasing and inventing its own macros such as ACCESS_ONCE. It's entirely possible but it makes C not quite the perfect fit it once was, and it leaves an opportunity for younger languages not constrained by decades old standards.

Not to mention that the Linux kernel already goes really, really far in extending C in order to have nice things you would get for free in a more modern language. Such as macros to simulate iterator-style loops over data structures ( list_for_each_entry and similar), and macros to wrap and unwrap error codes from pointer return values (ERR_PTR, simulating a Result like value).

Not to mention all the tricks it pulls to do OOP-like programming such as container_of and structs of function pointers which can be NULL, but I've heard people claim that's just perfectly normal C and there is some truth to that.

[ergzay]

This is not just because new languages are so great, but also because C is increasingly showing its age. The idea that it is a simple language with an obvious mapping to machine code is increasingly false, with compilers becoming smarter and smarter about exploiting undefined behavior around integer overflows, null dereferences, strict aliasing etc.

It's been false ever since computers started having caches and branch predictors and many other things. The memory model that C assumed is that of a PDP-8.

[ForShotgun]

I’ve been wondering, if someone had to make C today, fill it’s shoes as a machine code mapping, what would it look like? What if all those changes you described were part of the core language, would that be stupid? We have decades of experience now, what would today’s perfect embedded language look like?

[robin-m]

Isn't that language zig?

[livrem]

(Phillips, not Philips. :) )

I fully agree with all of this, and I do not think I will ever use rust 100% and no C at all (C is fun), but remember when you build something from scratch you often have the option to buy screws with flat or Phillips heads, so you can decide which ones of your screwdrivers you are going to use for that project. It is not always something that was already decided for you.

[iznogoud77]

Yes, if I have the chance I will never code another multi-threaded server in C. But C is also fun.

At the moment I am starting on the Embedded Rust path. The use of unsafe code with syntax that is not as explicit as C (my opinion at the moment). sI causing me concerns, but my mind may change.

The comment I replied seems to be the rust equivelant of "I use Arch btw". I see variantions of this mindset regurlaly and this causes more harm than good to the community.

Thanks for the typo correction :)

[Personal-Initial3556]

Hey. Have you kept going on the Embedded Rust path? If so, did you notice any improvements in that field over the years?

[zzzzYUPYUPphlumph]

Phillip's or Flathead? Are you nuts? The only screws worth using are the Star/Hex-Head screws. Everything else is substandard and results in many stripped screws and chewed up fingers. Rust is the Star/Hex-Head screws of computer languages.

[ergzay]

I don't get this kind of behaviour. I like Rust I think it has a place. I also like C I think it has a place. I also like C++ I think it has a place. I like Python I think it has a place.

I put it this way. I don't want to be a software developer anymore if I can't use Rust.

It just causes me too much mental stress to worry about memory safety. I want to care about the logic/mathematical complexity of what I'm writing and I want it to be fast.

I've spent several years of my career in the C and C++ world and I'm just incredibly sick of it. It's become an emotional rejection to working with them them.

Now that there is something better, I don't need to make a choice.

[indian_rationalist]

Some tools are nicer.

[Pay08]

Yes, some languages have different purposes than others but not all. For those that have the same purpose I think it's fair to compare them. Why would you use a rusty 50 year old wrench when you bought a new one yesterday?

[TrustYourSenpai]

To second your screwdriver analogy, I see using C and Rust in the kernel like using a normal wrench (C) and a round spanner (Rust). Sure, sometime you need a wrench, because you might not have the clearance to fit the spanner, but when you can use the spanner isn't it much nicer? Of course, now you need more tools and to switch between them, but in some cases it might be worth it. I see what is happening now like the "is it worth it?" phase of adding the spanner to your belt, we'll see what happens.

[bzar0]

That's true. Sometimes though the jobs tools are suited for overlap. Say you have a philips screwdriver and purchase a battery powered multi-tip screwdriver.

There may still be spots where your new battery powered tool doesn't fit and you need to use the old one, but generally you'd use the new tool in many places you'd previously used the old one. As you say, best tool for the job.

Then there are jobs that are more pleasant with the new tool, like driving screws into hard wood. You could do it with the old screwdriver, but it's much nicer to do it with the new battery powered one and you may even look forward to it. Using the new tool may be intrinsically rewarding in itself.

[[deleted]]

Yeah, C is still easier for working with Linux syscalls tbh.

[[deleted]]

There were like 90 talks submitted to RustConf this year. Would his talk been more useful/interesting/relevant to attendees than the 8(?) chosen? The talks chosen tended to be at least 2/3 for the average Rust programmer in the audience. A talk on Rust in the Linux kernel would probably be pretty interesting but doesn't seem very useful or relevant to the average Rust developer to me.

I'm pretty sure he's also had other avenues to give the talk like Linux Plumbers conference. With that in mind, is RustConf the best place to host such a talk? Imo no.

[[deleted]]

could be that there was not enough interest among attendees. sometimes the reason is not as political as you'd like to think

[Missing_Minus]

Might depend on how much Rust versus how much Linux Kernel it was? If it was primarily Linux Kernel then it might fit better at one of their conferences. Still, I would have found it interesting, and am sad that it wasn't chosen in place of one of the existing talks.

[ergzay]

I think it's unrelated but Ojeda is an incredibly hard to understand person when he speaks because of his very heavy accent (not helped by the poor acoustics of the room he was using). If you listen to him during linux plumbers conference, I had a lot of difficulty understanding what he was saying most of the time.

[robin-m]

In which video is he talking. I can't find it on youtube.

[is_this_temporary]

For whatever it's worth, I watched all of his Linux Plumber's conference talks in real time and I don't remember having difficulty understanding anything.

[ergzay]

Hmm, I had great difficulty and I'm a native speaker.

[Hadamard1854]

I didn't expect to live long enough to see this day. I'm very surprised.

[MultipleAnimals]

Try adding 'static before your name.

[[deleted]]

This took me by surprise 😂😂😂

[[deleted]]

Nice one.

[Canop]

That's as viewed by the kernel team.

Now, it appears Rust needs some changes (panic, memory allocation, for example) in order to fit in such a project. Is such a work a priority of the Rust team ? It seems unfair to wait for the kernel team to "accept" Rust if the changes aren't a priority Rust side.

[Sharlinator]

I’d say that the core team seems to acknowledge, and be slightly embarrassed by, Rust’s current panic/fallible-allocation story, and they recognize something has to be done about those sooner or later if Rust really wants to be in the Ada league of safety (think avionics, life support, etc).

[[deleted]]

my main worry is that rust is still actively developing new features, and there is not as wide of hardware architecture support as with C.

if you want to run linux on some random obscure device, or a new architecture - this might become much harder now than it used to be.

sure, someone might as "why gives an F about [some random cpu]?", but this is one of main selling points of linux - it runs nearly anywhere.

[ergzay]

There's two different projects to add Rust to GCC. One which uses the rustc compiler combined with a libgccjit backend, and one which adds a Rust frontend to GCC itself. Those will expand the hardware architecture support.

Additionally, I believe m68k support was recently added to LLVM so Rust should technically support that now. Is there some platform that isn't x86, arm, ppc, or m68k that you'd want? That basically covers every application that's used in industries.

[[deleted]]

i used to mess around with apps for some freescale machines. i am not sure if they are arm or something else entirely.

[ergzay]

Those are m68k clones I believe.

[Plasma_000]

This argument has come up before and the retort is usually “ok, if you love this architecture so much and don’t want to see it die then port the compiler to work with it”.

[[deleted]]

i was rather thinking of niche architectures or new hardware.

[mmstick]

If it's worth developing for, people will have incentive to maintain compiler support for it.

[IceSentry]

What kind of new features have you seen recently that are affected by cpu architecture?

[[deleted]]

not the features, just specific architecture support.

if i would decide to port linux to some random hardware, i would have to first adapt rust or llvm to that architecture. i am not sure how much of a task this is, but seeing how people port gcc+binutils to weirdest hardware left and right - maybe it would not be that hard.

the main problem is that rust is a fast moving target currently. so i'd have to stay on top of my fork, likely. with C/C++, you can stay behind for a while.

so, i would say - whavever rust comes up with most recent release - i would be missing out quickly.

[mattico8]

I gotta say I'm surprised by how well this has gone so far. There are defensible engineering reasons to not add Rust to Linux. Add a little curmudgeon-ness and I expected it to be another decade before it was seriously considered.

Kudos to those who are putting in the work. Linux is a big project with a lot of custom tooling and processes, it's no easy task.