3 ms·

The goal of rust for linux isn't to wholesale translate linux into rust, but simply to be able to write pieces of linux (largely new ones) in rust. I think it's

by gpm 2y ago

The goal of rust for linux isn't to wholesale translate linux into rust, but simply to be able to write pieces of linux (largely new ones) in rust. I think it's very unlikely anyone (including google) will take on a wholesale translation anytime soon. That said > It's unlikely that Google has much sway here Google has helped fund the rust for linux project pretty much from the start [1], they're one of three organizations mentioned on the homepage due to their sponorship [2]. They're actively involved in it, and have already ported their android "binder" driver into it with the intent to ship it in android. This strikes me as a very weird take. [1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-rust-in-linux/ https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru... [2] https://rust-for-linux.com/ https://rust-for-linux.com/

adgjlsfhk1 2y ago
One of the really nice parts of the Rust linux project is that the new Rust code is getting a some of the memory management patterns in the C code actually written down rather than just being in the heads of the programmers.
- lenkite 2y ago
  Can you please explain what this means ? Isn't it now just in Rust code instead of C code ? Or is there some design documentation being written around this ?
  - yazaddaruvala 2y ago
    My understanding is there is a bunch of poorly documented C code that is being translated into Rust using strict types. This can simplify a bunch when using Rust but also better documents the internals for C.
    - gpm 2y ago
      Translated is really the wrong word here. Rust bindings for it are being written so you can call the C code from safe rust. The C code still exists and only the api is duplicated into rust. The convenient side effect of that is that you need to know what constraints you have to enforce to make that memory safe, and generally memory safe here is going to translate to knowing how to properly call the api and enforcing that. Very little C code is actually being rewritten in rust. None of the core C code that is really at issue here (but, for example, android's binder driver has been rewritten).
vlovich123 2y ago
Google is a contributor but you’re going to have a bad time if you think that Google is some monolithic entity. While a part of Google is funding it, other Googlers may be maintainers that are opposed to helping the project (eg look at the article about the rust for Linux maintainer stepping down due to burnout from politics and the comments made my Ted Tso a Google employee against the R4L project). But yes, R4L is a thing that’s still going on but it’s unrelated to rust in firmware unless you bucket everything Rust together. R4L is adapting Rust and establishing conventions and build systems relevant only to the Linux kernel and that’s not necessarily a whole lot in common with firmware projects which are typically managed and maintained very differently with very different build systems.
- gpm 2y ago
  Yep, I agree with all that.

by gpm 2y ago

adgjlsfhk1 2y ago

One of the really nice parts of the Rust linux project is that the new Rust code is getting a some of the memory management patterns in the C code actually written down rather than just being in the heads of the programmers.

lenkite 2y ago
Can you please explain what this means ? Isn't it now just in Rust code instead of C code ? Or is there some design documentation being written around this ?
- yazaddaruvala 2y ago
  My understanding is there is a bunch of poorly documented C code that is being translated into Rust using strict types. This can simplify a bunch when using Rust but also better documents the internals for C.
  - gpm 2y ago
    Translated is really the wrong word here. Rust bindings for it are being written so you can call the C code from safe rust. The C code still exists and only the api is duplicated into rust. The convenient side effect of that is that you need to know what constraints you have to enforce to make that memory safe, and generally memory safe here is going to translate to knowing how to properly call the api and enforcing that. Very little C code is actually being rewritten in rust. None of the core C code that is really at issue here (but, for example, android's binder driver has been rewritten).

vlovich123 2y ago

Google is a contributor but you’re going to have a bad time if you think that Google is some monolithic entity. While a part of Google is funding it, other Googlers may be maintainers that are opposed to helping the project (eg look at the article about the rust for Linux maintainer stepping down due to burnout from politics and the comments made my Ted Tso a Google employee against the R4L project). But yes, R4L is a thing that’s still going on but it’s unrelated to rust in firmware unless you bucket everything Rust together. R4L is adapting Rust and establishing conventions and build systems relevant only to the Linux kernel and that’s not necessarily a whole lot in common with firmware projects which are typically managed and maintained very differently with very different build systems.

gpm 2y ago
Yep, I agree with all that.