6 ms·

It's an interesting discussion. There's always a divide when you slowly migrate from one thing to another. What makes this interesting is that the difference b

It's an interesting discussion. There's always a divide when you slowly migrate from one thing to another. What makes this interesting is that the difference between C code an Rust code is not something you can just ignore. You will lose developers who simply don't want or can spend the time to get into the intricacies of a new language. And you will temporarily have a codebase where 2 worlds collide. I wonder how in retrospect they will think about the decisions they made today.

bayindirh 2y ago
I don't think changing to Rust code completely is something attainable. I guess some older or more closer to the metal parts will stay in C, but parts seeing more traffic and evolution will be more rusty after some time, and both will have its uses and have their islands inside the codebase. gccrs will allow the whole thing to be built with GCC toolchain in a single swoop. If banks are still using COBOL and FORTRAN here and there, this will be the most probable possibility in my eyes.
- leonheld 2y ago
  > I guess some older or more closer to the metal parts will stay in C I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things. This reminds me I need to do some non-trivial embedded project with Rust to see how it behaves in that regard. I'm not sure if the abstraction gets in the way.
  - bayindirh 2y ago
    After writing some non-trivial and performance sensitive C/C++ code, you have feeling of how that code behave on the real metal. I have that kind of intuition, for example. I never had to dive to the level of generated ASM, but I can get ~80% of theoretical IPC with just minding what I'm doing in C++ (minimum branching, biasing branches towards a certain side, etc.). So, I think if you do the same thing with Rust, you'll have that intuition, as well. I have a friend who writes embedded Rust, and he said it's not as smooth as C, yet. I think Rust has finished the first 90% of its maturing, and has the other 90%.
    - pclmulqdq 2y ago
      I am not convinced, given the amount of heavy lifting that the Rust type system does, that rusty Rust is nearly as brain-compilable as C. However, you can write the equivalent of C in many languages, and Rust is one of them. That kind of code is easy to compile in your head.
      - bayindirh 2y ago
        It's not brain-compilability, it's getting used to what that specific compiler does with your code you brain-compile. So, I have a model for my code in my brain, and this code also has a real-world behavior after it's compiled by your favorite toolchain. You do both enough times, and you'll have a feeling for both your code and the compiler's behavior for your code. This feeling breaks when you change languages. I can brain-compile Go for example, but compiler adds other things like GC and null-pointer protection (carry local variables to heap if you're going to hit a null pointer exception after returning a function). Getting used to this takes time. Same for Rust.
    - sakian 2y ago
      I write embedded rust full-time and can say there's nothing that I can do in C that I can't do in rust. Sure the tools/frameworks are a lot more mature, but a combination of the PAC for register access (maybe a bit of community maintained HAL) and a framework like RTIC is pretty much all I need.
  - xg15 2y ago
    > I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things This is the only way Hellwig's objection makes any kind of sense to me. Obviously, intra-kernel module boundaries are no REST-APIs, where providers and clients would be completely separated from each other. Here I imagine that both the DMA module as well as its API consumers are compiled together into a monolithic binary, so if assumptions about the API consumers change, this could affect how the module itself is compiled.
  - the__alchemist 2y ago
    I've done a non-trivial embedded project in C. (Quadcopter firmware). The language doesn't get in the way, but I had to write my own tooling in many areas.
- flir 2y ago
  Is there a layer where C is the sweet spot? Something too high-level for ASM, and too low-level for Rust? (not my area, so genuine question).
  - bayindirh 2y ago
    Directly programming hardware with bit-banging, shifts, bitmasks and whatnot. Too cumbersome in ASM to do in large swaths, too low level for Rust or even for C++. Plus for that kind of things you have "deterministic C" styles which guarantee things will be done your way, all day, every day. For everyone answering: This is what I understood by chatting with people who write Rust in amateur and pro settings. It's not something of a "Rust is bad" bias or something. The general consensus was, C is closer to the hardware and allows handling of quirks of the hardware better, because you can do "seemingly dangerous" things which hardware needs to be done to initialize successfully. Older hardware is finicky, just remember that. Also, for anyone wondering. I'll start learning Rust the day gccrs becomes usable. I'm not a fan of LLVM, and have no problems with Rust.
    - hkwerf 2y ago
      Why exactly would it be too low-level for Rust?
    - dralley 2y ago
      > too low level for Rust or even for C++. I'd love to hear a justification for why this is a thing. Doing bit-banging is no more difficult in Rust or C++ than in C.
      - friendzis 2y ago
        You probably mean "C compatible-ish subset of C++98"
      - dartos 2y ago
        Two reasons I can think of off the top of my head. The assembly outputted from C compilers tend to be more predictable by virtue of C being a simpler language. This matters when writing drivers for exotic hardware. Sometimes to do things like make a performant ring buffer (without vec dequeue) you need to use unsafe rust anyway, which IMO is just taking the complexity of the rust language without any of the benefit. I don’t really think there’s any benefit to using C++ over rust except that it interfaces with C code more easily. IMO that’s not a deal maker.
Sharlin 2y ago
Most likely Rust will stay strictly on the driver side for several years still. It's a very natural Schelling fence for now, and the benefits are considerable, both in improving driver quality and making it less intimidating to contribute to driver code. It will also indirectly improve the quality of core code and documentation by forcing the many, many underspecified and byzantine API contracts to be made more rigorous (and hopefully simplified). This is precisely one of the primary things that have caused friction between RfL and the old guard: there are lots and lots of things you just "need to know" in order to soundly call many kernel APIs, and that doesn't square well with trying to write safe(r) Rust abstractions over them.
- Tyr42 2y ago
  An example of the latter: drm_sched https://vt.social/@lina/113051677686279824 https://vt.social/@lina/113051677686279824
  - 12345hn6789 2y ago
    [flagged]
  - Vilian 2y ago
    What's the link for the lkml drama?
    - steveklabnik 2y ago
      I'm not sure but I'm guessing it's this one https://lore.kernel.org/lkml/20230714-drm-sched-fixes-v1-0-c567249709f7@asahilina.net/ https://lore.kernel.org/lkml/20230714-drm-sched-fixes-v1-0-c...
- renewedrebecca 2y ago
  > and that doesn't square well with trying to write safe(r) Rust abstractions over them. Or just using those kernel APIs, period.
pyrale 2y ago
> I wonder how in retrospect they will think about the decisions they made today. The decision was not made today, what happens today (or, rather, a few days ago) is Linus calling out a C maintainer going out of his way to screw rust devs. Rust devs have also been called out for shitty behaviour in the process. The decision to run a Rust experiment is a thing that can be (and is) criticized, but if you allow people to willfully sabotage the process in order to sink the experiment, you will also lose plenty of developers.

bayindirh 2y ago

I don't think changing to Rust code completely is something attainable. I guess some older or more closer to the metal parts will stay in C, but parts seeing more traffic and evolution will be more rusty after some time, and both will have its uses and have their islands inside the codebase. gccrs will allow the whole thing to be built with GCC toolchain in a single swoop. If banks are still using COBOL and FORTRAN here and there, this will be the most probable possibility in my eyes.

leonheld 2y ago
> I guess some older or more closer to the metal parts will stay in C I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things. This reminds me I need to do some non-trivial embedded project with Rust to see how it behaves in that regard. I'm not sure if the abstraction gets in the way.
- bayindirh 2y ago
  After writing some non-trivial and performance sensitive C/C++ code, you have feeling of how that code behave on the real metal. I have that kind of intuition, for example. I never had to dive to the level of generated ASM, but I can get ~80% of theoretical IPC with just minding what I'm doing in C++ (minimum branching, biasing branches towards a certain side, etc.). So, I think if you do the same thing with Rust, you'll have that intuition, as well. I have a friend who writes embedded Rust, and he said it's not as smooth as C, yet. I think Rust has finished the first 90% of its maturing, and has the other 90%.
  - pclmulqdq 2y ago
    I am not convinced, given the amount of heavy lifting that the Rust type system does, that rusty Rust is nearly as brain-compilable as C. However, you can write the equivalent of C in many languages, and Rust is one of them. That kind of code is easy to compile in your head.
    - bayindirh 2y ago
      It's not brain-compilability, it's getting used to what that specific compiler does with your code you brain-compile. So, I have a model for my code in my brain, and this code also has a real-world behavior after it's compiled by your favorite toolchain. You do both enough times, and you'll have a feeling for both your code and the compiler's behavior for your code. This feeling breaks when you change languages. I can brain-compile Go for example, but compiler adds other things like GC and null-pointer protection (carry local variables to heap if you're going to hit a null pointer exception after returning a function). Getting used to this takes time. Same for Rust.
  - sakian 2y ago
    I write embedded rust full-time and can say there's nothing that I can do in C that I can't do in rust. Sure the tools/frameworks are a lot more mature, but a combination of the PAC for register access (maybe a bit of community maintained HAL) and a framework like RTIC is pretty much all I need.
- xg15 2y ago
  > I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things This is the only way Hellwig's objection makes any kind of sense to me. Obviously, intra-kernel module boundaries are no REST-APIs, where providers and clients would be completely separated from each other. Here I imagine that both the DMA module as well as its API consumers are compiled together into a monolithic binary, so if assumptions about the API consumers change, this could affect how the module itself is compiled.
- the__alchemist 2y ago
  I've done a non-trivial embedded project in C. (Quadcopter firmware). The language doesn't get in the way, but I had to write my own tooling in many areas.
flir 2y ago
Is there a layer where C is the sweet spot? Something too high-level for ASM, and too low-level for Rust? (not my area, so genuine question).
- bayindirh 2y ago
  Directly programming hardware with bit-banging, shifts, bitmasks and whatnot. Too cumbersome in ASM to do in large swaths, too low level for Rust or even for C++. Plus for that kind of things you have "deterministic C" styles which guarantee things will be done your way, all day, every day. For everyone answering: This is what I understood by chatting with people who write Rust in amateur and pro settings. It's not something of a "Rust is bad" bias or something. The general consensus was, C is closer to the hardware and allows handling of quirks of the hardware better, because you can do "seemingly dangerous" things which hardware needs to be done to initialize successfully. Older hardware is finicky, just remember that. Also, for anyone wondering. I'll start learning Rust the day gccrs becomes usable. I'm not a fan of LLVM, and have no problems with Rust.
  - hkwerf 2y ago
    Why exactly would it be too low-level for Rust?
  - dralley 2y ago
    > too low level for Rust or even for C++. I'd love to hear a justification for why this is a thing. Doing bit-banging is no more difficult in Rust or C++ than in C.
    - friendzis 2y ago
      You probably mean "C compatible-ish subset of C++98"
    - dartos 2y ago
      Two reasons I can think of off the top of my head. The assembly outputted from C compilers tend to be more predictable by virtue of C being a simpler language. This matters when writing drivers for exotic hardware. Sometimes to do things like make a performant ring buffer (without vec dequeue) you need to use unsafe rust anyway, which IMO is just taking the complexity of the rust language without any of the benefit. I don’t really think there’s any benefit to using C++ over rust except that it interfaces with C code more easily. IMO that’s not a deal maker.

Sharlin 2y ago

Most likely Rust will stay strictly on the driver side for several years still. It's a very natural Schelling fence for now, and the benefits are considerable, both in improving driver quality and making it less intimidating to contribute to driver code. It will also indirectly improve the quality of core code and documentation by forcing the many, many underspecified and byzantine API contracts to be made more rigorous (and hopefully simplified). This is precisely one of the primary things that have caused friction between RfL and the old guard: there are lots and lots of things you just "need to know" in order to soundly call many kernel APIs, and that doesn't square well with trying to write safe(r) Rust abstractions over them.

Tyr42 2y ago
An example of the latter: drm_sched https://vt.social/@lina/113051677686279824 https://vt.social/@lina/113051677686279824
- 12345hn6789 2y ago
  [flagged]
- Vilian 2y ago
  What's the link for the lkml drama?
  - steveklabnik 2y ago
    I'm not sure but I'm guessing it's this one https://lore.kernel.org/lkml/20230714-drm-sched-fixes-v1-0-c567249709f7@asahilina.net/ https://lore.kernel.org/lkml/20230714-drm-sched-fixes-v1-0-c...
renewedrebecca 2y ago
> and that doesn't square well with trying to write safe(r) Rust abstractions over them. Or just using those kernel APIs, period.

pyrale 2y ago

> I wonder how in retrospect they will think about the decisions they made today. The decision was not made today, what happens today (or, rather, a few days ago) is Linus calling out a C maintainer going out of his way to screw rust devs. Rust devs have also been called out for shitty behaviour in the process. The decision to run a Rust experiment is a thing that can be (and is) criticized, but if you allow people to willfully sabotage the process in order to sink the experiment, you will also lose plenty of developers.