Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Rust language features for kernel development

lwn.net

Post reply on HN
Print view View original

81–90 of 240 posts

Re: Upcoming Rust language features for kernel development

#81

Post by Dr_Emann »

remix2000 wrote: post #64
tobz1000 wrote: post #61

Earlier quoted context omitted.

The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.

I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.

Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)

Re: Upcoming Rust language features for kernel development

#82

Post by koverstreet »

izacus wrote: post #55
koverstreet wrote: post #51

Earlier quoted context omitted.

"Experiment" is a misnomer. Rust has been around long enough and demonstrated more than enough real advantages in writing reliable code that we know it's what we want to be doing.

But WHERE is that code in the kernel? That, I think, it the OPs point. Where is that demonstration?

It's been moving slowly at first because you need a lot of bindings done before you can do interesting work, and bindings/FFI tend to be fiddly, error prone things that you want to take your time on and get right - that's where you deal with the impedance mismatch between C and Rust and have to get all the implicit rules expressed in the type system (if you can).

It'll go faster once all the bindings are in place and people have more experience with this stuff. I've been greatly looking forward to expanding bcachefs's use of rust, right now it's just in userspace but I've got some initial bindings for bcachefs's core btree API.

Real iterators, closures, better data types, all that stuff is going to be so nice when it can replace pages and pages of macro madness.

Re: Upcoming Rust language features for kernel development

#83

Post by mekoka »

a-dub wrote: post #66
dmm wrote: post #49

Earlier quoted context omitted.

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet. """ Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and al…

> Torvalds seems to disagree with you. i don't really care for mindless appeals to authority. make your own arguments and defend them or don't bother. this gpu driver looks pretty cool though. looks like there's much more to the rust compatibility layer in the asahi tree and it is pretty cool that they were able to ship so quickly. i'd be curious how kernel rust compares to user space rust with respect to bloat. (use…

Mindless appeal to authority? I don't think that's how the fallacy really works. It's pretty much the authority that seems to disagree with your sentiment, that is if we can agree that Torvalds still knows what he's doing. Him not sharing your skepticism is a valid argument. The point being that instead of giving weight to our distant feelings, maybe we could just pause and be more curious as to why someone with much closer involvement would not share them. Why should we care more about the opinions of randos on hn?

Re: Upcoming Rust language features for kernel development

#84

Post by serious8aller »

a-dub wrote: post #66
dmm wrote: post #49

Earlier quoted context omitted.

The gpu driver for Apple silicon is Rust and the author stated it would have been much more difficult to implement in C. It isn't upstreamed yet. """ Normally, when you write a brand new kernel driver as complicated as this one, trying to go from simple demo apps to a full desktop with multiple apps using the GPU concurrently ends up triggering all sorts of race conditions, memory leaks, use-after-free issues, and al…

> Torvalds seems to disagree with you. i don't really care for mindless appeals to authority. make your own arguments and defend them or don't bother. this gpu driver looks pretty cool though. looks like there's much more to the rust compatibility layer in the asahi tree and it is pretty cool that they were able to ship so quickly. i'd be curious how kernel rust compares to user space rust with respect to bloat. (use…

Not every mention of an authority's opinion needs to be interpreted as an "appeal to authority". In this case I think they're just trying to give you perspective, not use Torvalds opinion as words from god.

Re: Upcoming Rust language features for kernel development

#85

Post by aw1621107 »

Foxboron wrote: post #46
muvlon wrote: post #31

Earlier quoted context omitted.

C interop is excellent and has been for years. The one piece that still needs unstable is defining/exposing varargs functions (support for calling them was stabilized many years ago). You can write almost anything you can write in C in (partly unsafe) Rust, in fact there are projects like c2rust that automate this translation. These new features are all about making things that the kernel devs need possible in safe R…

> C interop is excellent and has been for years. Only if you primarily work with `cargo` and want to interact with C from Rust. The other way around has far less support and `rustc` does not standardize the object generation. This is actively preventing projects like `systemd` to adopt Rust into their project as an example. https://github.com/systemd/systemd/pull/19598

> Only if you primarily work with `cargo` and want to interact with C from Rust.

In what way(s) does Rust's C interop depend on cargo?

> The other way around has far less support and `rustc` does not standardize the object generation.

I believe in this context the understanding is that you're going to be using `extern "C"` and/or `#[repr(C)]` in your Rust code, which gives you a plain C interface. I think attempting to use "raw" Rust code from other languages is a rare phenomenon, if it's even attempted at all.

> This is actively preventing projects like `systemd` to adopt Rust into their project as an example.

Could you point out specific instances from that thread? From a quick glance I didn't see any obvious instances of someone saying that using Rust from C is problematic.

Re: Upcoming Rust language features for kernel development

#86

Post by remix2000 »

Dr_Emann wrote: post #81
remix2000 wrote: post #64

Earlier quoted context omitted.

I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.

Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)

And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?

Re: Upcoming Rust language features for kernel development

#87

Post by emn13 »

remix2000 wrote: post #64
tobz1000 wrote: post #61

Earlier quoted context omitted.

The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.

I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.

I mean, reliably tracking ownership and therefore knowing that e.g. an aliased write must complete before a read is surely helpful?

It won't prevent all races, but it might help avoid mistakes in a few of em. And concurrency is such a pain; any such machine-checked guarantees are probably nice to have to those dealing with em - caveat being that I'm not such a person.

Re: Upcoming Rust language features for kernel development

#88

Post by a-dub »

tialaramex wrote: post #74
William_BB wrote: post #65

Earlier quoted context omitted.

What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing?

> What does rust have to do with thread safety [...] ? Rust inherently models this idea. Read about Rust's "Send" and "Sync" marker traits. e.g. https://doc.rust-lang.org/std/marker/trait.Send.html > Is rust going to synchronize shared memory access for me? Much better than that. (safe) Rust is going to complain that you can't write the unsynchronized nonsense you were probably going to write, shortcutting the step w…

aren't they just annotations? proper use of mutexes and lock ordering aren't that hard, they just require a little bit of discipline and consistency.

i can't remember the last time i faced a data race to be honest.

i guess the real question is, how well does it all hold up when you have teamwork and everything isn't strictly adherent to one specific philosophy.

Re: Upcoming Rust language features for kernel development

#89

Post by arnsholt »

corbet wrote: post #62
izacus wrote: post #55

Earlier quoted context omitted.

But WHERE is that code in the kernel? That, I think, it the OPs point. Where is that demonstration?

See, for example, the binder driver merged for 6.18. It's out there, and will land when it's ready.

In discussions like this, I sometimes feel that the importance of related work like the increasing use of Rust in Android and MS land is under-appreciated. Those who think C is fine often (it seems to me) make arguments along the lines that C just needs to have a less UB-prone variant along the lines of John Regehr and colleagues' "Friendly C" proposal,[0] which unfortunately Regehr about a year and a half later concluded couldn't really be landed by a consensus approach.[1] But he does suggest a way forwards: "an influential group such as the Android team could create a friendly C dialect and use it to build the C code (or at least the security-sensitive C code) in their project", which is what I would argue is happening; it's just that rather than nailing down a better C, several important efforts are all deciding that Rust is the way forward.

The avalanche has already started. It is too late for the pebbles to vote.

0: https://blog.regehr.org/archives/1180 1: https://blog.regehr.org/archives/1287

Re: Upcoming Rust language features for kernel development

#90

Post by saghm »

a-dub wrote: post #47

> The Rust for Linux project has been good for Rust i just decided do a good ol' 'find -name "*.rs"' in the kernel tree to get a sense for what all this is about. from what i can tell, there's just an api compatibility layer (found in /rust) and then a smattering of proof of concept drivers in tree that appear to just be simple rewrites of existing drivers (with the exception of the incomplete nvidia thing) that aren…

It's hard to view the relatively small scope of existing Rust code in the kernel at the present time as an indictment of the utility of Rust being used in the kernel when there are major kernel maintainers who have publicly stated that they have been doing everything in their power to block any amount of Rust code from getting merged into any part of the codebase.
Post reply on HN