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

71–80 of 240 posts

Re: Upcoming Rust language features for kernel development

#71

Post by jdub »

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.

a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value

Re: Upcoming Rust language features for kernel development

#72

Post by Lvl999Noob »

William_BB wrote: post #65
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…

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?

Rust's design eliminates data races completely. It also makes it much easier to write thread safe code from the start. Race conditions are possible but generally less of a thing compared to C++ (at least that's what I think).

Nothing is preventing you from writing correct C++ code. Rust is strictly less powerful (in terms of possible programs) than C++. The problem with C++ is that the easiest way to do anything is often the wrong way to do it. You might not even realize you are sharing a variable across threads and that it needs to be atomic.

Re: Upcoming Rust language features for kernel development

#73

Post by [deleted] »

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.

[deleted]

Re: Upcoming Rust language features for kernel development

#74

Post by tialaramex »

William_BB wrote: post #65
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…

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 where in production everything gets corrupted and you spend six months trying to reproduce and debug your mistake...

Re: Upcoming Rust language features for kernel development

#75

Post by timschmidt »

afishhh wrote: post #58
pjmlp wrote: post #10

Earlier quoted context omitted.

Only if those userspace applications are headless, Rust exceling at GUIs is a bit of a strech.

> Rust exceling at GUIs is a bit of a strech. I strongly agree with this. In particular the Rust GUI libraries I've looked at have text layout / rendering that is nowhere near what should be considered adequate today (imo). For example egui: - It doesn't do any bidi reordering. - It also doesn't do any font fallback so even if you didn't need bidi you can't render many languages without first acquiring an appropriate…

This is a detail oriented list of real issues, which is wonderful! ChatGPT found open issues in the egui Github for each of your problems, so they're known about and being worked on.

However, it seems like most of the other UI toolkits discussed here, even in other languages, suffer similar issues. Which points to the difficulty of the problems. Consequently, I don't have any problem praising egui and Rust alongside. They're great! And even great can always get better! :)

Re: Upcoming Rust language features for kernel development

#76

Post by a-dub »

15155 wrote: post #70
a-dub wrote: post #66

Earlier quoted context omitted.

> 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…

> i don't really care for mindless appeals to authority. This isn't an appeal to just any authority, but the authority that defines Linux and is its namesake.

[flagged]

Re: Upcoming Rust language features for kernel development

#78

Post by aw1621107 »

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…

> from what i can tell even the android binder rust rewrite is vestigial.

Vestigal how? The commit message in the version in Linus's tree (from commit eafedbc7c050c44744fbdf80bdf3315e860b7513 "rust_binder: add Rust Binder driver") makes it seem rather more complete:

> Rust binder passes all tests that validate the correctness of Binder in the Android Open Source Project. We can boot a device, and run a variety of apps and functionality without issues. We have performed this both on the Cuttlefish Android emulator device, and on a Pixel 6 Pro.

> As for feature parity, Rust binder currently implements all features that C binder supports, with the exception of some debugging facilities. The missing debugging facilities will be added before we submit the Rust implementation upstream.

----

> shouldn't this experiment in programming language co-development be taking place somewhere other than the source tree for the world's most important piece of software?

Rust for Linux did start as an out-of-tree project. The thing is that no matter how much work you do out of tree if you're serious about trying integration out you'll have to pull in experimental support at some point - which is more or less what is happening now.

Re: Upcoming Rust language features for kernel development

#79

Post by remix2000 »

jdub wrote: post #71
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.

a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value

I meant the trait send sync things. I just thought it was obvious, since Rust is not the only language susceptible to data races.

Re: Upcoming Rust language features for kernel development

#80

Post by ynx »

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…

To be fair, assigning the highly competent BDFL of Linux who has listened to a bunch of highly competent maintainers some credibility isn't mindless.

Unless you have a specific falsifiable claim that is being challenged or defended, it's not at all a fallacy to assume expert opinions are implicitly correct. It's just wisdom and good sense, even if it's not useful to the debate you want to have.

Post reply on HN