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

121–130 of 240 posts

Re: Upcoming Rust language features for kernel development

#121

Post by anarki8 »

pjmlp wrote: post #10
timschmidt wrote: post #8

Earlier quoted context omitted.

> for everything else on userspace compiled managed languages are a much better option As someone who's written a number of userspace applications in many languages as well as embedded firmwares running on bare metal, Rust is a rare gem that excels at both.

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

I wouldn't say it's bad at GUIs either. There are some nice libraries like Iced and Slint. Some even have good accessibility support like egui.

There is a full-fledged DE written in Rust that uses Iced: https://en.wikipedia.org/wiki/COSMIC_(desktop_environment)

Re: Upcoming Rust language features for kernel development

#122

Post by WD-42 »

pjmlp wrote: post #10
timschmidt wrote: post #8

Earlier quoted context omitted.

> for everything else on userspace compiled managed languages are a much better option As someone who's written a number of userspace applications in many languages as well as embedded firmwares running on bare metal, Rust is a rare gem that excels at both.

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

The GTK bindings are fine.

Re: Upcoming Rust language features for kernel development

#123

Post by penguin_booze »

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…

> 'find -name ".rs"'

Since this is a Git repo, I'd go with `git ls-files '.rs'`.

Re: Upcoming Rust language features for kernel development

#124

Post by piperswe »

drdo wrote: post #115
anon-3988 wrote: post #113

fn project_reference(r: &MyStruct) -> &Field { &r.field } unsafe fn project_pointer(r: *mut MyStruct) -> *mut Field { unsafe { &raw mut (*r).field } } // The equivalent C code would look like this: struct field *project(struct my *r) { return &(r->field); } I am a very heavy Rust user. I mostly program in safe Rust while occassionally dipping into unsafe Rust. IDK, I think Rust should stick with what it is good at an…

It's not that hard to implement a linked list in Rust in exactly the same way as in C or C++, using raw pointers, and putting a safe API around it.

In fact, IIRC exactly that is available in the standard library.

Re: Upcoming Rust language features for kernel development

#125

Post by uecker »

gpm wrote: post #107
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.

I'm not sure I understand the point of your comment at all. Rust does, successfully, guarantee the lack of data races. It also guarantees the lack of memory-unsafety resulting from race conditions in general (which to be fair largely just means "it guarantees a lack of data races", though it does also include things like "race conditions won't result in a use after free or an out of bounds memory access"). If by addr…

Safe Rust does. To the extend Rust interfaces that wrap kernel APIs will achieve safety for the drivers that make use of them remains to be seen. I think it will indeed do this to some degree, but I have some doubts whether the effort and overhead is worth it. IMHO all these resources would better be invested elsewhere.

Re: Upcoming Rust language features for kernel development

#126

Post by RGBCube »

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

It is much more complex than C, sure. But it's so much simpler than C++ and you won't find yourself digging through the reference, or standard, or whatever to understand the code you are writing. It's very close to the sweet spot of "not complex enough to make you bald, not simple enough to make your code complex" while also making correctness the default.

Re: Upcoming Rust language features for kernel development

#127

Post by uecker »

arnsholt wrote: post #89
corbet wrote: post #62

Earlier quoted context omitted.

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

Some parts of the industry with a lot of money and influence decided this is the way forward. IMHO Rust has the same issue as C++: it is too complex and a memory safe C would be far more useful. It is sad that not more resources are invested into this.

Re: Upcoming Rust language features for kernel development

#128

Post by turtleyacht »

AlotOfReading wrote: post #102
a-dub wrote: post #88

Earlier quoted context omitted.

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.

Proper use of lock ordering is reasonably difficult in a large, deeply connected codebase like a kernel. Rust has real improvements here, like this example from the fuschia team of enforcing lock ordering at compile time [0]. This is technically possible in C++ as well (see Alon Wolf's metaprogramming), but it's truly dark magic to do so. [0] https://lwn.net/Articles/995814/

Borrow Checker, Lifetimes, and Destructor Arguments in C++ (2024)

https://a10nw01f.github.io/post/advanced_compile_time_valida...

Re: Upcoming Rust language features for kernel development

#129

Post by School-Cotton »

bobajeff wrote: post #100

Looking at the rust rfc for the lightweight clones feature [1]. It took me a while to sort of understand it. Once I did I was excited for the feature but after awhile I was once again struck by the observation that rust is a very complex language to learn. To me as someone who's not learned either it looks like all the concepts and features of 'true' modern C++ (as opposed to C + a few extra features) spliced with th…

Rust is more complex than C, yes, but as someone who has used both professionally, it is not even close to being as complex as C++. In fact it is closer in complexity to C than to C++.

Re: Upcoming Rust language features for kernel development

#130

Post by School-Cotton »

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 and race conditions? Is rust going to synchronize shared memory access for me?

Well, pretty close to that, actually! Rust will statically prevent you from accessing the same data from different threads concurrently without using a lock or atomic.

> what's preventing me from using C++ atomics to achieve the same thing

You might forget?

Post reply on HN