6 ms·

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

by a-dub 1y ago

> 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't even really in use. from what i can tell even the android binder rust rewrite is vestigial. the whole thing seems kinda cute but like, 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? redox is a pretty cool experimental piece of software that might be the os of the future, why not do it there?

dmm 1y ago
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 all kinds of badness. But all that just… didn’t happen! I only had to fix a few logic bugs and one issue in the core of the memory management code, and then everything else just worked stably! Rust is truly magical! Its safety features mean that the design of the driver is guaranteed to be thread-safe and memory-safe as long as there are no issues in the few unsafe sections. It really guides you towards not just safe but good design. """ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ > the whole thing seems kinda cute but like, 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? Torvalds seems to disagree with you.
- remix2000 1y ago
  Rustlang doesn't aim to address race conditions. Sounds to me like overly "cautious" inefficient code you can write in any language. Think using `std::shared_ptr` for everything in C++, perchance…?
  - tobz1000 1y ago
    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.
    - remix2000 1y ago
      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.
      - jdub 1y ago
        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
        remix2000 1y ago
        I meant the trait send sync things. I just thought it was obvious, since Rust is not the only language susceptible to data races.
        masklinn 1y ago
        > since Rust is not the only language susceptible to data races. The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.
      - deleted 1y ago
        [deleted]
      - Dr_Emann 1y ago
        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)
- giancarlostoro 1y ago
  I was just going to say, I think its hard to argue against it since it is the only way to run the GPU on the M1 / M2 Macs.
- William_BB 1y ago
  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?
  - Aurornis 1y ago
    > What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Rust’s strict ownership model enforces more correct handling of data that is shared or sent across threads. > Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing? C++ is not used in the Linux kernel. You can write safe code in C++ or C if everything is attended to carefully and no mistakes are made by you or future maintainers who modify code. The benefit of Rust is that the compiler enforces it at a language level so you don’t have to rely on everyone touching the code avoiding mistakes or the disallowed behavior.
  - Lvl999Noob 1y ago
    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.
  - tialaramex 1y ago
    > 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 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...
- a-dub 1y ago
  > 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. (user rust is pretty bad in that regard, imo)
  - 15155 1y ago
    > 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.
    - a-dub 1y ago
      [flagged]
      - EGG_CREAM 1y ago
        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.
      - mynameisash 1y ago
        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.
        lesuorac 1y ago
        Eh? Surely it's better to cite the authority's reasons as to why they think this way than just to cite the authority itself ... It's not like there's a lack of times he's talked about rust. Just link his commentary similar to linking ashai linux.
koverstreet 1y ago
"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.
- izacus 1y ago
  But WHERE is that code in the kernel? That, I think, it the OPs point. Where is that demonstration?
  - corbet 1y ago
    See, for example, the binder driver merged for 6.18. It's out there, and will land when it's ready.
    - arnsholt 1y ago
      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 https://blog.regehr.org/archives/1180 1: https://blog.regehr.org/archives/1287 https://blog.regehr.org/archives/1287
      - uecker 1y ago
        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.
the8472 1y ago
Before you can have complex drivers you need the interface layer that the drivers are built on. The RfL project works on that, upstreaming more infrastructure work until there's enough to submit a complex driver. Redhat is working on nova, asahi on the apple GPU, collabora is working on one for ARM Mali. If 3 GPU drivers don't count as complex, real drivers then what does?
aw1621107 1y ago
> 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.
saghm 1y ago
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.
dralley 1y ago
> 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 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.
testdelacc1 1y ago
> 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
penguin_booze 1y ago
> 'find -name ".rs"' Since this is a Git repo, I'd go with `git ls-files '.rs'`.
nicoburns 1y ago
> 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? The language co-development isn't unique to Rust. There are plenty of features in GCC and Clang that exist specifically for Kernel usage too.
chippiewill 1y ago
The point of the project is not meant to be an experiment in "programming language co-development", the point of the project is to use Rust in Linux kernel development. The project was started by Linux kernel developers who want to use Rust. It's been a slow start, but as you say, it's the world's most important piece of software so progress has been careful and trying to get the foundations right before going crazy with it. The fact that Rust gets to benefit from the project too is just an added bonus.
mustache_kimono 1y ago
> redox is a pretty cool experimental piece of software that might be the os of the future, why not do it there? Because people want to use Rust where they use C, right now? Whereas yours is a perfectly fine criticism, it ignores that people want the good stuff, everywhere, in the things they actually use every day. And since this is something the project lead wants to do, this doesn't seem to problem/live issue.
yencabulator 1y ago
> there's just an api compatibility layer (found in /rust) Even figuring out what exactly the Linux kernel API safety rules are is a huge task, much less encoding them in a computer-readable form. The code there is not about C<->Rust FFI. It's about encoding Linux kernel API properties into a safe Rust API. The uncertainty of the calling/ordering rules is exactly why kernel C has been hard to write. For VFS locking rules, you pretty much have to simulate Al Viro's brain and replay his whole life experience...

by a-dub 1y ago

dmm 1y ago

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 all kinds of badness. But all that just… didn’t happen! I only had to fix a few logic bugs and one issue in the core of the memory management code, and then everything else just worked stably! Rust is truly magical! Its safety features mean that the design of the driver is guaranteed to be thread-safe and memory-safe as long as there are no issues in the few unsafe sections. It really guides you towards not just safe but good design. """ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ > the whole thing seems kinda cute but like, 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? Torvalds seems to disagree with you.

remix2000 1y ago
Rustlang doesn't aim to address race conditions. Sounds to me like overly "cautious" inefficient code you can write in any language. Think using `std::shared_ptr` for everything in C++, perchance…?
- tobz1000 1y ago
  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.
  - remix2000 1y ago
    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.
    - jdub 1y ago
      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
      - remix2000 1y ago
        I meant the trait send sync things. I just thought it was obvious, since Rust is not the only language susceptible to data races.
        masklinn 1y ago
        > since Rust is not the only language susceptible to data races. The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.
    - deleted 1y ago
      [deleted]
    - Dr_Emann 1y ago
      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)
giancarlostoro 1y ago
I was just going to say, I think its hard to argue against it since it is the only way to run the GPU on the M1 / M2 Macs.
William_BB 1y ago
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?
- Aurornis 1y ago
  > What does rust have to do with thread safety and race conditions? Is rust going to synchronize shared memory access for me? Rust’s strict ownership model enforces more correct handling of data that is shared or sent across threads. > Speaking seriously, they surely meant data races, right? If so, what's preventing me from using C++ atomics to achieve the same thing? C++ is not used in the Linux kernel. You can write safe code in C++ or C if everything is attended to carefully and no mistakes are made by you or future maintainers who modify code. The benefit of Rust is that the compiler enforces it at a language level so you don’t have to rely on everyone touching the code avoiding mistakes or the disallowed behavior.
- Lvl999Noob 1y ago
  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.
- tialaramex 1y ago
  > 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 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...
a-dub 1y ago
> 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. (user rust is pretty bad in that regard, imo)
- 15155 1y ago
  > 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.
  - a-dub 1y ago
    [flagged]
    - EGG_CREAM 1y ago
      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.
    - mynameisash 1y ago
      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.
      - lesuorac 1y ago
        Eh? Surely it's better to cite the authority's reasons as to why they think this way than just to cite the authority itself ... It's not like there's a lack of times he's talked about rust. Just link his commentary similar to linking ashai linux.

koverstreet 1y ago

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

izacus 1y ago
But WHERE is that code in the kernel? That, I think, it the OPs point. Where is that demonstration?
- corbet 1y ago
  See, for example, the binder driver merged for 6.18. It's out there, and will land when it's ready.
  - arnsholt 1y ago
    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 https://blog.regehr.org/archives/1180 1: https://blog.regehr.org/archives/1287 https://blog.regehr.org/archives/1287
    - uecker 1y ago
      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.

the8472 1y ago

Before you can have complex drivers you need the interface layer that the drivers are built on. The RfL project works on that, upstreaming more infrastructure work until there's enough to submit a complex driver. Redhat is working on nova, asahi on the apple GPU, collabora is working on one for ARM Mali. If 3 GPU drivers don't count as complex, real drivers then what does?

aw1621107 1y ago

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

saghm 1y ago

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.

dralley 1y ago

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

testdelacc1 1y ago

> 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

penguin_booze 1y ago

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

nicoburns 1y ago

> 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? The language co-development isn't unique to Rust. There are plenty of features in GCC and Clang that exist specifically for Kernel usage too.

chippiewill 1y ago

The point of the project is not meant to be an experiment in "programming language co-development", the point of the project is to use Rust in Linux kernel development. The project was started by Linux kernel developers who want to use Rust. It's been a slow start, but as you say, it's the world's most important piece of software so progress has been careful and trying to get the foundations right before going crazy with it. The fact that Rust gets to benefit from the project too is just an added bonus.

mustache_kimono 1y ago

> redox is a pretty cool experimental piece of software that might be the os of the future, why not do it there? Because people want to use Rust where they use C, right now? Whereas yours is a perfectly fine criticism, it ignores that people want the good stuff, everywhere, in the things they actually use every day. And since this is something the project lead wants to do, this doesn't seem to problem/live issue.

yencabulator 1y ago

> there's just an api compatibility layer (found in /rust) Even figuring out what exactly the Linux kernel API safety rules are is a huge task, much less encoding them in a computer-readable form. The code there is not about C<->Rust FFI. It's about encoding Linux kernel API properties into a safe Rust API. The uncertainty of the calling/ordering rules is exactly why kernel C has been hard to write. For VFS locking rules, you pretty much have to simulate Al Viro's brain and replay his whole life experience...