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

91–100 of 240 posts

Re: Upcoming Rust language features for kernel development

#91

Post by dralley »

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.

This is incorrect. The android binder rust rewrite is planned to wholly replace the current C implementation.

https://www.phoronix.com/news/Rust-Binder-For-Linux-6.18

And most of the big drivers written for Apple M-series hardware are written in Rust, those are not simple rewrites or proof of concepts.

Re: Upcoming Rust language features for kernel development

#92

Post by namr2000 »

muvlon wrote: post #31
heavyset_go wrote: post #14

Earlier quoted context omitted.

What's the story with C interop now with these and related changes? I'm out of the loop.

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…

I have to disagree here a little bit. Calling C functions from Rust is a very pleasant experience, but the other way around is not so nice. You usually have to manually create types that will unpack rust collections into C compatible structures (think decomposing `Vec` into ptr, len, capacity) & then ensure that memory passed between the two sides is free'd with the appropriate allocator. Even with `cbindgen` taking care of the mindless conversions for you, you still have to put a lot of thought into the API between the two languages.

I am currently working on a fairly involved C & Rust embedded systems project and getting the inter-language interface stable and memory-leak free took a good amount of effort. It probably didn't help that I don't have access to valgrind or gdb on this platform.

Re: Upcoming Rust language features for kernel development

#93

Post by aw1621107 »

a-dub wrote: post #88
tialaramex wrote: post #74

Earlier quoted context omitted.

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

> aren't they just annotations?

"Just" annotations... that are automatically added (in the vast majority of cases) and enforced by the compiler.

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

Yes, like how avoiding type confusion/OOB/use-after-free/etc. "just require[s] a little bit of discipline and consistency"?

The point of offloading these kinds of things onto the compiler/language is precisely so that you have something watching your back if/when your discipline and consistency slips, especially when dealing with larger/more complex systems/teams. Most of us are only human, after all.

> how well does it all hold up when you have teamwork and everything isn't strictly adherent to one specific philosophy.

Again, part of the point is that Send/Sync are virtually always handled by the compiler, so teamwork and philosophy generally aren't in the picture in the first place. Consider it an extension of your "regular" strong static type system checks (e.g., can't pass object of type A to a function that expects an unrelated object of type B) to cross-thread concerns.

Re: Upcoming Rust language features for kernel development

#94

Post by jcranmer »

a-dub wrote: post #88
tialaramex wrote: post #74

Earlier quoted context omitted.

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

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

Spatial memory safety is easy, just check the bounds before indexing an array. Temporal memory safety is easy, just free memory only after you've finished using it, and not too early or too late. As you say, thread safety is easy.

Except we have loads of empirical evidence--from widespread failures of software--that it's not easy in practice. Especially in large codebases, remembering the remote conditions you need to uphold to maintain memory safety and thread safety can be difficult. I've written loads of code that created issues like "oops, I forgot to account for the possibility that someone might use this notification to immediately tell me to shut down."

What these annotations provide is a way to have the compiler bop you in the head when you accidentally screw something up, in the same way the compiler bops you in the head if you fucked up a type or the name of something. And my experience is that many people do go through a phase with the borrow checker where they complain about it being incorrect, only to later discover that it was correct, and the pattern they thought was safe wasn't.

Re: Upcoming Rust language features for kernel development

#95

Post by EGG_CREAM »

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

Earlier quoted context omitted.

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

It’s very intellectually lazy of you not to be curious about why the creator and decades long, knowledgeable guardian of Linux has the opposite opinion as you, all because you read the Wikipedia about logical fallacies one time.

Re: Upcoming Rust language features for kernel development

#96

Post by aw1621107 »

namr2000 wrote: post #92
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…

I have to disagree here a little bit. Calling C functions from Rust is a very pleasant experience, but the other way around is not so nice. You usually have to manually create types that will unpack rust collections into C compatible structures (think decomposing `Vec` into ptr, len, capacity) & then ensure that memory passed between the two sides is free'd with the appropriate allocator. Even with `cbindgen` taking…

I feel this might come down to the scope one has in mind when thinking of the word "interop". I think one can reasonably simultaneously claim that the interop "mechanics" are excellent in that it's generally possible to create a Rust library that quacks like a C library and that basically any C library is usable by Rust code, but the interop "ergonomics" are suboptimal in that (as you say) actually writing the glue code can be a bit of an adventure.

Re: Upcoming Rust language features for kernel development

#97

Post by mynameisash »

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

Earlier quoted context omitted.

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

Also the guy that created "the world's most important piece of software", as you put it. Appealing to the authority on the exact thing you raised concern about is the single most important authority one can cite.

Re: Upcoming Rust language features for kernel development

#98

Post by testdelacc1 »

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…

> shouldn’t this be taking place somewhere else

That’s an interesting idea. You should let this guy know you disagree with his technical decision -> torvalds@linux-foundation.org

Re: Upcoming Rust language features for kernel development

#99

Post by namr2000 »

aw1621107 wrote: post #96
namr2000 wrote: post #92

Earlier quoted context omitted.

I have to disagree here a little bit. Calling C functions from Rust is a very pleasant experience, but the other way around is not so nice. You usually have to manually create types that will unpack rust collections into C compatible structures (think decomposing `Vec` into ptr, len, capacity) & then ensure that memory passed between the two sides is free'd with the appropriate allocator. Even with `cbindgen` taking…

I feel this might come down to the scope one has in mind when thinking of the word "interop". I think one can reasonably simultaneously claim that the interop "mechanics" are excellent in that it's generally possible to create a Rust library that quacks like a C library and that basically any C library is usable by Rust code, but the interop "ergonomics" are suboptimal in that (as you say) actually writing the glue c…

I think that's a fair assessment. To your point `cbindgen` makes the mechanics of the whole thing painless & linking was trivial. That's worth a lot especially when compared to other languages.

Re: Upcoming Rust language features for kernel development

#100

Post by bobajeff »

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 the features and concepts of Haskell.

Yet people seem to like making useful things in it so it must have gotten something right. So I'll probably get around to attempting to really use it again.

[1]: https://github.com/joshtriplett/rfcs/blob/use/text/3680-use....

Post reply on HN