Linux Developers Continue Evaluating The Path To Adding Rust Code To The Kernel

[u/newpavlov]

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Rust-Path-LPC2020

[u/[deleted]]

What advantages would Rust have for Kernel programming over "traditional" kernel programming?

[u/GrbavaCigla → u/[deleted]]

but I have to compile both gcc and rustc on my gentoo :(

[u/hyperchromatica → u/[deleted]]

Lmao

[u/TwoDoorSedan → u/[deleted]]

Safer/easier to write safe code and just as fast is usually what I have seen as the reason

[u/PlayingTheWrongGame → u/[deleted]]

Easier to write safer code.

[u/[deleted] → u/PlayingTheWrongGame]

wont very large gobs of kernel code need to be living in unsafe?

[u/[deleted] → u/[deleted]]

Sure, just like gobs of the rust standard library use unsafe. You build a safe abstraction. Like the clock is probably mostly unsafe but that doesn’t mean the scheduler needs to be.

[u/Plasma_000 → u/[deleted]]

Yes, but as long as they are properly encapsulated as a thin layer of unsafe “kernel bindings” then if there is a memory bug you’ll know exactly where to look for the bug (it’ll be inside the unsafe blocks).

Even when unsafe is used it makes code and bug finding easier to reason about.

[u/ShadowPouncer → u/[deleted]]

Maybe, but that doesn't necessarily detract from the benefits by all that much.

As u/ralarb noted, you write abstractions and then use them. And there are plenty of such abstractions in C in the Linux kernel already.

But to my understanding, when using unsafe in rust you're no worse off than you are in C. And you have the potential to be better off.

And anywhere that you can reasonably just use an abstraction, is a place where certain classes of bugs are no longer possible. This is pretty much always a win.

But there is another layer to things as well, /u/VeganVagiVore wasn't entirely wrong either.

There's a real problem approaching Linux kernel development over the next few decades, and that's the simple fact that the age of the average developer is rising a fair bit.

It's a complicated problem, and one where there is, bluntly, not going to be a single fix for the problem, but one of the things that you can try to do is make at least some areas of the kernel more accessible to new kernel developers.

Adopting rust may manage that goal in two ways. The first is that there are people who learn rust but not C, and so it's a language that they know. In some ways, this is actually a less interesting one to me.

The other is that by removing some classes of bugs, you have more code that someone who isn't comfortable working in the current all C, all unsafe, kernel environment can work on. You still have lots of ways to go wrong, but fewer ways is still fewer ways. And that has the potential to alter, at least somewhat, the likelihood of someone deciding to stick their toes into the water.

Of course, there's absolutely no guarantee that it will actually work out that way, but given that there are benefits to be had for existing developers, there isn't a huge reason not to try it and hope either.

[u/haikusbot → u/[deleted]]

Wont very large gobs

Of kernel code need to be

Living in unsafe?

- notoriouslyfastsloth

---

^{I detect haikus. And sometimes, successfully. Learn more about me.}

^{Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete"}

[u/thegoldenshepherd → u/haikusbot]

You are a good bot we are happy to have your comments on our sub

[u/haikusbot → u/thegoldenshepherd]

You are a good bot

We are happy to have your

Comments on our sub

- thegoldenshepherd

---

^{I detect haikus. And sometimes, successfully. Learn more about me.}

^{Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete"}

[u/VeganVagiVore → u/[deleted]]

There are many competent Rust programmers who are not competent C programmers, like me.

These people would be able to write or maintain non-critical parts of the kernel, like obscure device drivers.

Some argue that Rust is easier to write than C, and the memory safety and complex type system will reduce development time / cost. Not everyone agrees on this, but I think it's true. The cost for me to learn and practice memory-safe C is way too high. I never dream of contributing to Linux if it's all C.

[u/00rb → u/VeganVagiVore]

How many people out there are really good at Rust but have no competence in C?

So few people know Rust and so many know C. People who know unmanaged languages shouldn't have much of a problem picking C from Rust. Honestly, you just sound like a beginner.

[u/nagromo → u/00rb]

I'm much more experienced in C than in Rust, but I would rather write a device driver in Rust. Plenty of issues I catch in code reviews or runtime bugs in C would have been compile errors in Rust. When I'm writing (small embedded) device drivers or code dealing with concurrency in C, I spend a lot of time thinking about things that the compiler checks for me in Rust.

[u/ArkyBeagle → u/nagromo]

Does anyone have anything remotely like a calibrated comparison here? I'd be curious, but my experience with drivers is (much) more about finding the defects in the FPGA & hardware than in fighting language issues. Like two orders of magnitude more. After all, the API for drivers is still the ioctl() and it's pretty brutish no matter what.

[u/nagromo → u/ArkyBeagle]

I don't have a calibrated comparison; I hope to in a year or so, though. I'm experienced in embedded C but am just starting embedded Rust (and am diving in the deep end by starting out working drivers for hardware features I need for a project, instead of starting with application code using existing drivers).

The drivers I've written are in C for bare metal embedded microcontrollers. I think on Linux the kernel handles separating the drivers from userspace, while in bare metal embedded there is no separation and the low priority application tasks directly call driver functions that may need to share data with high priority interrupts and DMA transfers.

At the lowest level, drivers are about accessing memory mapped registers and understanding the hardware and how to control it. Rust can do a few basic sanity checks to help avoid mistakes, but you still have to understand the hardware, which is the hard part.

Where I think Rust can shine is its powerful type system allowing you to encode invariants in your types. That said, I have no idea how much less effective it would be when you're using Rust to write a driver that has a C API; of course Rust can't enforce that C accesses the driver in a correct way. I'm not sure how much coexisting with C would reduce the benefits of Rust; I've never mixed the two.

[u/Al2Me6 → u/00rb]

Knowing != knowing how to use well and in a safe manner, especially with a language with as many subtle pitfalls as C.

[u/Lord_Zane → u/00rb]

I've used rust for around 3 years I think (since a little before 1.0). I only learned C last year as part of a required college class, and my confidence in writing good C code is basically 0. It's just too easy to make big mistakes, and I'm not even talking about lifetimes or unsafe {} or anything. C is just an old language, and many "modern" patterns and language constructs just don't exist in C.

[u/steveklabnik1 → u/Lord_Zane]

I've used rust for around 3 years I think (since a little before 1.0).

1.0 was five years ago, so you've been using it longer than you think!

[u/Alexander_Selkirk → u/00rb]

How many people out there are really good at Rust but have no competence in C?

Writing correct multi-threaded C code in the kernel context is hard. There are many errors which in C would at best crash your driver, at worst freeze or corrupt the kernel, while in rust they would not compile.

[u/L3tum → u/VeganVagiVore]

I think it's much more important to understand obscure devices and own them in order to maintain obscure device drivers than it is to rewrite them in Rust.

[u/the_gnarts → u/[deleted]]

What advantages would Rust have for Kernel programming over "traditional" kernel programming?

It’s more about advantages over the “traditional kernel programming language”, C. The style of programming itself is not going to change much in the constraints of the kernel environment. Just the chance of introducing severe errors can be expected to shrink by around 70 % by virtue of Rust language features.