5 ms·

I'm an outsider, only submitted one tiny patch years ago, but it seems like this Rust for Linux initiative will end badly if it's not stopped. You have so many

I'm an outsider, only submitted one tiny patch years ago, but it seems like this Rust for Linux initiative will end badly if it's not stopped. You have so many people involved in work on this open source OS written in C and they will be pushed to accepting foreign code. Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving?

zozbot234 2y ago
We now have https://github.com/FractalFir/rustc_codegen_clr#c-support https://github.com/FractalFir/rustc_codegen_clr#c-support . So we can keep all our Rust files out-of-tree and just submit C code like everyone else.
- michaelanckaert 2y ago
  I can't image what reviewing C code like that would look like? Rust is a complex piece of technology, is the transpiled C code 'clean' enough to be able to review it?
  - varjag 2y ago
    It certainly isn't. Getting even C code written by human with best effort for addressing standards and conventions accepted is challenging enough.
- kmeisthax 2y ago
  This violates the GPL.
  - zozbot234 2y ago
    It doesn't, because C code is clearly "the preferred form for modification" by C kernel devs that, by their own admission, are quite unwilling to deal with the perceived complexity of a multi-language code base. (Or even to learn any other programming language, for that matter.)
paulddraper 2y ago
> maybe we will see the existing maintainers leaving That is probably true. The reasons for Rust are compelling. And the uncountable value of the Linux kernel justifies a lot of pain.
estebank 2y ago
Are you aware that RfL is not outsider Rust enthusiasts pushing on the kernel, but rather existing Linux kernel developers wanting to use Rust?
- lukaslalinsky 2y ago
  Internal or external, it doesn't change much. Either Rust usage remains very isolated, or Rust takes Linux over and who doesn't want to deal with Rust should leave. Even the policy acknowledges, that the rust team being responsible for fixing broken rust builds is only temporary.
  - 0x457 2y ago
    Is the goal to make a good kernel or to keep C developers happy? I don't see rust taking over C in kernel ever. re: broken rust builds You should think very very hard on when it can break and how it effects C side of things.
empath75 2y ago
Eventually, there are going to be more experienced Rust developers than there are experienced C developers.
- varjag 2y ago
  Most people reading this will switch careers from IC before that happens.
  - ZeWaka 2y ago
    Independent Contributor?
    - saagarjha 2y ago
      I guess the NSA was really behind the commits all along
criticalfault 2y ago
There were also a lot of times mentioned that current maintainers are getting old. Rust people might, with time, take over... being younger and all.
motorest 2y ago
> Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving? What are you talking about? I'm yet to work at a business where developers aren't proficient in 2 or more programming languages. Why do you presume that experts in the field would be blocked by a limitation that does not apply to the vast majority of professional software developers?
- 0x457 2y ago
  I have work on such companies unless you count TypeScript and JavaScript as two languages. Comment you're replying to is about some kernel developers not wanting to learn/write/use rust.
owl_vision 2y ago
and eventually create this totally new language full of certainty and more...
saagarjha 2y ago
Every other engineering organization on the planet seems to do just fine with a polyglot codebase. Do you really think kernel maintainers are dumber than the average Google engineer?
kmeisthax 2y ago
Rust was specifically designed to integrate well into a C codebase; and Rust for Linux was specifically for drivers - not to replace all of Linux's internals. The two things that putting Rust in Linux actually requires of existing C maintainers is: - They have to not get in the way of Rust bindings - They have to document critical pre- and post-conditions of their code that impact memory safety That last one is a problem - not one that Rust caused, but a problem that's been in Linux nonetheless. This is the thing that all the BSDs hate on Linux for. Typically, the approach to handling big breaking changes with Linux kernel objects is "make it compile, then change all the things that crash until they stop crashing". This means there isn't any documentation to write safe bindings for any Linux kernel function, since it could, say, rely on you calling three other functions in a specific order that just so happens to match the one major driver that uses that subsystem[0]. For Rust bindings to make sense and actually provide value, the subsystem maintainers need to provide documentation that they usually don't bother with. The first one on the list is the reason why Hector Martin ragequit his maintainer position and decided upstreaming Asahi drivers isn't worth doing. There's a few subsystem maintainers that internally decided "I don't care what Linus thinks, fuck Rust". One of them happens to be the maintainer for the DMA subsystem, which happens to be... fairly critical to writing any non-toy driver. The problem is specifically that there isn't a push for Rust. Linus is uncharacteristically fence-sitting here, to the point where people are writing Rust drivers that can't be upstreamed because his own maintainers are blocking them. Having the kernel support two languages is fine, but it requires Linus actually put his foot down and either say "stop treating the Rust people like Nvidia and let them write safe bindings to kernel internals," or, "we're not going to do Rust at all because of X, Y, or Z." [0] I am told amdgpu is like this.
- gauntletstricky 2y ago
  [flagged]
  - aw1621107 2y ago
    > Sources requested. I don't even know why you'd claim this. I think the original quote is most favorably interpreted in comparison to other languages with a runtime that require external C code to know its calling into another language (for example, Python with manual calls to increment/decrement refcounts). One of the reasons Rust dropped its original runtime was specifically to allow it to "pretend" to be regular C code - if you build it to be consumed as a C library external C code can use it and be none the wiser that it is calling into another language. There's also other affordances for playing well with C (extern "C", no_mangle, #[repr(C)], etc.) In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code. > Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries. I'm not sure that example is particularly relevant. At least at a high level it seems the primary reason the hyper backend was removed was because of a lack of interest rather than some innate issue with Rust interop. If anything, the continued existence of the other two Rust backends would seem to hint that Rust interop is not really that much of an issue.

zozbot234 2y ago

We now have https://github.com/FractalFir/rustc_codegen_clr#c-support https://github.com/FractalFir/rustc_codegen_clr#c-support . So we can keep all our Rust files out-of-tree and just submit C code like everyone else.

michaelanckaert 2y ago
I can't image what reviewing C code like that would look like? Rust is a complex piece of technology, is the transpiled C code 'clean' enough to be able to review it?
- varjag 2y ago
  It certainly isn't. Getting even C code written by human with best effort for addressing standards and conventions accepted is challenging enough.
kmeisthax 2y ago
This violates the GPL.
- zozbot234 2y ago
  It doesn't, because C code is clearly "the preferred form for modification" by C kernel devs that, by their own admission, are quite unwilling to deal with the perceived complexity of a multi-language code base. (Or even to learn any other programming language, for that matter.)

paulddraper 2y ago

> maybe we will see the existing maintainers leaving That is probably true. The reasons for Rust are compelling. And the uncountable value of the Linux kernel justifies a lot of pain.

estebank 2y ago

Are you aware that RfL is not outsider Rust enthusiasts pushing on the kernel, but rather existing Linux kernel developers wanting to use Rust?

lukaslalinsky 2y ago
Internal or external, it doesn't change much. Either Rust usage remains very isolated, or Rust takes Linux over and who doesn't want to deal with Rust should leave. Even the policy acknowledges, that the rust team being responsible for fixing broken rust builds is only temporary.
- 0x457 2y ago
  Is the goal to make a good kernel or to keep C developers happy? I don't see rust taking over C in kernel ever. re: broken rust builds You should think very very hard on when it can break and how it effects C side of things.

empath75 2y ago

Eventually, there are going to be more experienced Rust developers than there are experienced C developers.

varjag 2y ago
Most people reading this will switch careers from IC before that happens.
- ZeWaka 2y ago
  Independent Contributor?
  - saagarjha 2y ago
    I guess the NSA was really behind the commits all along

criticalfault 2y ago

There were also a lot of times mentioned that current maintainers are getting old. Rust people might, with time, take over... being younger and all.

motorest 2y ago

> Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving? What are you talking about? I'm yet to work at a business where developers aren't proficient in 2 or more programming languages. Why do you presume that experts in the field would be blocked by a limitation that does not apply to the vast majority of professional software developers?

0x457 2y ago
I have work on such companies unless you count TypeScript and JavaScript as two languages. Comment you're replying to is about some kernel developers not wanting to learn/write/use rust.

owl_vision 2y ago

and eventually create this totally new language full of certainty and more...

saagarjha 2y ago

Every other engineering organization on the planet seems to do just fine with a polyglot codebase. Do you really think kernel maintainers are dumber than the average Google engineer?

kmeisthax 2y ago

Rust was specifically designed to integrate well into a C codebase; and Rust for Linux was specifically for drivers - not to replace all of Linux's internals. The two things that putting Rust in Linux actually requires of existing C maintainers is: - They have to not get in the way of Rust bindings - They have to document critical pre- and post-conditions of their code that impact memory safety That last one is a problem - not one that Rust caused, but a problem that's been in Linux nonetheless. This is the thing that all the BSDs hate on Linux for. Typically, the approach to handling big breaking changes with Linux kernel objects is "make it compile, then change all the things that crash until they stop crashing". This means there isn't any documentation to write safe bindings for any Linux kernel function, since it could, say, rely on you calling three other functions in a specific order that just so happens to match the one major driver that uses that subsystem[0]. For Rust bindings to make sense and actually provide value, the subsystem maintainers need to provide documentation that they usually don't bother with. The first one on the list is the reason why Hector Martin ragequit his maintainer position and decided upstreaming Asahi drivers isn't worth doing. There's a few subsystem maintainers that internally decided "I don't care what Linus thinks, fuck Rust". One of them happens to be the maintainer for the DMA subsystem, which happens to be... fairly critical to writing any non-toy driver. The problem is specifically that there isn't a push for Rust. Linus is uncharacteristically fence-sitting here, to the point where people are writing Rust drivers that can't be upstreamed because his own maintainers are blocking them. Having the kernel support two languages is fine, but it requires Linus actually put his foot down and either say "stop treating the Rust people like Nvidia and let them write safe bindings to kernel internals," or, "we're not going to do Rust at all because of X, Y, or Z." [0] I am told amdgpu is like this.

gauntletstricky 2y ago
[flagged]
- aw1621107 2y ago
  > Sources requested. I don't even know why you'd claim this. I think the original quote is most favorably interpreted in comparison to other languages with a runtime that require external C code to know its calling into another language (for example, Python with manual calls to increment/decrement refcounts). One of the reasons Rust dropped its original runtime was specifically to allow it to "pretend" to be regular C code - if you build it to be consumed as a C library external C code can use it and be none the wiser that it is calling into another language. There's also other affordances for playing well with C (extern "C", no_mangle, #[repr(C)], etc.) In that sense, Rust is indeed specifically designed to play well in C codebases as the rest of the C code can basically pretend it's only working with C code. > Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries. I'm not sure that example is particularly relevant. At least at a high level it seems the primary reason the hyper backend was removed was because of a lack of interest rather than some innate issue with Rust interop. If anything, the continued existence of the other two Rust backends would seem to hint that Rust interop is not really that much of an issue.