4 ms·

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

"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.
      - gpm 1y ago
        I'm entirely unconvinced that a low-level† memory safe C that is meaningfully simpler than rust is even possible, let alone desirable. IMHO Basically all of rust's complexity comes from implementing the structure necessary to make it memory safe without making it too difficult to use††. Even if it is though, we don't have it. It seems like linux should go with the solution we have in hand and can see works, not a solution that hasn't been developed or proved possible and practical. Nor is memory safety the only thing rust brings to the table, it's also brings a more expressive type system that prevents other mistakes (just not as categorically) and lets you program faster. Supposing we got this memory safe C that somehow avoided this complexity... I don't think I'd even want to use it over the more expressive memory safe language that also brings other benefits. † A memory-safe managed C is possible of course (see https://fil-c.org/ https://fil-c.org/), but it seems unsuitable for a kernel. †† There are some other alternatives to the choices rust made, but not meaningfully less complex. Separately you could ditch the complexity of async I guess, but you can also just use rust as if async didn't exist, it's a purely value added feature. There's likely one or two other similar examples though they don't immediately come to mind.
        uecker 1y ago
        I don't think so. First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Second, I do not even believe that memory safety is that important that this trumps other considerations, e.g. the complexity of having two languages in the kernel (even if you ignore the complexity of Rust). Now, it is not my decision but Google's and other company's influence. But I still think it is a mistake and highlights more the influence of certain tech companies on open source than anything else.
    - Pet_Ant 1y ago
      Oof. That's a depressing read: > This post is a long-winded way of saying that I lost faith in my ability to push the work forward. The gem of despair: > Another example is what should be done when a 32-bit integer is shifted by 32 places (this is undefined behavior in C and C++). Stephen Canon pointed out on twitter that there are many programs typically compiled for ARM that would fail if this produced something besides 0, and there are also many programs typically compiled for x86 that would fail when this evaluates to something other than the original value.
- koverstreet 1y ago
  It's been moving slowly at first because you need a lot of bindings done before you can do interesting work, and bindings/FFI tend to be fiddly, error prone things that you want to take your time on and get right - that's where you deal with the impedance mismatch between C and Rust and have to get all the implicit rules expressed in the type system (if you can). It'll go faster once all the bindings are in place and people have more experience with this stuff. I've been greatly looking forward to expanding bcachefs's use of rust, right now it's just in userspace but I've got some initial bindings for bcachefs's core btree API. Real iterators, closures, better data types, all that stuff is going to be so nice when it can replace pages and pages of macro madness.
- School-Cotton 1y ago
  The main real-world example of Rust kernel code is the Asahi GPU driver, which has not merged upstream yet, but it does use the upstream interfaces you're seeing.

"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.
    - gpm 1y ago
      I'm entirely unconvinced that a low-level† memory safe C that is meaningfully simpler than rust is even possible, let alone desirable. IMHO Basically all of rust's complexity comes from implementing the structure necessary to make it memory safe without making it too difficult to use††. Even if it is though, we don't have it. It seems like linux should go with the solution we have in hand and can see works, not a solution that hasn't been developed or proved possible and practical. Nor is memory safety the only thing rust brings to the table, it's also brings a more expressive type system that prevents other mistakes (just not as categorically) and lets you program faster. Supposing we got this memory safe C that somehow avoided this complexity... I don't think I'd even want to use it over the more expressive memory safe language that also brings other benefits. † A memory-safe managed C is possible of course (see https://fil-c.org/ https://fil-c.org/), but it seems unsuitable for a kernel. †† There are some other alternatives to the choices rust made, but not meaningfully less complex. Separately you could ditch the complexity of async I guess, but you can also just use rust as if async didn't exist, it's a purely value added feature. There's likely one or two other similar examples though they don't immediately come to mind.
      - uecker 1y ago
        I don't think so. First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Second, I do not even believe that memory safety is that important that this trumps other considerations, e.g. the complexity of having two languages in the kernel (even if you ignore the complexity of Rust). Now, it is not my decision but Google's and other company's influence. But I still think it is a mistake and highlights more the influence of certain tech companies on open source than anything else.
  - Pet_Ant 1y ago
    Oof. That's a depressing read: > This post is a long-winded way of saying that I lost faith in my ability to push the work forward. The gem of despair: > Another example is what should be done when a 32-bit integer is shifted by 32 places (this is undefined behavior in C and C++). Stephen Canon pointed out on twitter that there are many programs typically compiled for ARM that would fail if this produced something besides 0, and there are also many programs typically compiled for x86 that would fail when this evaluates to something other than the original value.
koverstreet 1y ago
It's been moving slowly at first because you need a lot of bindings done before you can do interesting work, and bindings/FFI tend to be fiddly, error prone things that you want to take your time on and get right - that's where you deal with the impedance mismatch between C and Rust and have to get all the implicit rules expressed in the type system (if you can). It'll go faster once all the bindings are in place and people have more experience with this stuff. I've been greatly looking forward to expanding bcachefs's use of rust, right now it's just in userspace but I've got some initial bindings for bcachefs's core btree API. Real iterators, closures, better data types, all that stuff is going to be so nice when it can replace pages and pages of macro madness.
School-Cotton 1y ago
The main real-world example of Rust kernel code is the Asahi GPU driver, which has not merged upstream yet, but it does use the upstream interfaces you're seeing.