6 ms·

I have a hard time seeing this happen. Rust has most of the same properties which prevent C++'s inclusion in-tree. (Look up Linus' opinions on C++ if you aren't

I have a hard time seeing this happen. Rust has most of the same properties which prevent C++'s inclusion in-tree. (Look up Linus' opinions on C++ if you aren't already familiar.) Further, as far as I can tell, Rust currently lacks mainline GCC support which I believe will be a blocker.

maccam94 6y ago
I am assuming that it would work with clang-compiled[1] kernels only at first. 1: https://www.kernel.org/doc/html/latest/kbuild/llvm.html https://www.kernel.org/doc/html/latest/kbuild/llvm.html
- est31 6y ago
  Why would it require clang for the C components? The Rust compiler creates native libraries which can be linked to compilation units created by both clang and gcc, unless there's something special going on in the kernel that I'm not aware of.
- cesarb 6y ago
  Not really. Unless you want LTO, the object files generated by GCC and LLVM are compatible, and can mixed without issues.
photon12 6y ago
The thing is the kernel is kinda hurting for maintainers and opening up the path for the next generation of systems programmers (most of whom don't want to touch C any more than they have to) has to be something Linus is more likely to prioritize than in previous decades.
- CommieDetector 6y ago
  >next generation of systems programmers (most of whom don't want to touch C any more than they have to) Then they fail to quality as the next generation of system programmers.
- bibabaloo 6y ago
  > The thing is the kernel is kinda hurting for maintainers Source? AFAIK the kernel is probably one of the most, if not the most, well-funded and maintained open source projects.
  - novas0x2a 6y ago
    From the horse's mouth: https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ https://www.theregister.com/2020/06/30/hard_to_find_linux_ma...
    - est31 6y ago
      > We do not have enough maintainers. We do have a lot of people who write code, we have a fair number of maintainers, but... it's hard to find people who really look at other people's code and funnel that code upstream all the way, eventually, to my tree... It is one of the main issues we have.
      - aflag 6y ago
        If I read this correctly, they have a lot of contributors, but few people willing to follow through with the code so it gets all the way up to Linus' tree. I don't see how rust would really help there.
        ordu 6y ago
        It could be. Maybe there will not be more reviewers, but the process of reviewing could be faster. For example, in the kernel there are inline functions, which accept a constant (known at compile time) integer argument, and they make a switch or loop over that integer. The trick is to force compiler to inline function and to throw away most of switch's cases, or unroll loop completely, or make some other optimizations based on knowledge of the passed integer value. Such a functions are exported to a public kernel API sometimes. So any kernel developer could call them. It make unavoidable a mistake of a programmer, when some of those functions was called with an unknown at compile time integer value. It is not a bug as it is, code would compile and work nevertheless, code would be bigger that it could be, maybe slower, that's all. But reviewer should be finding such a misuse of API. It is just one example, linux kernel uses a lot of tricks and exposes it via APIs, reviewer must be aware of all of them and to check everything by itself. Compare it with Rust. In rust one can encode a lot more limits on the right use of an API than in C. Encode and enforce. Even when rust sometimes cannot do it, rust have nice macros, instead of C's macro-horror. So a lot of mistakes that could be made with C, could be avoided with Rust. So it would be easy to review code, it would take less time from a reviewer to review code.
- Glavnokoman 6y ago
  I for one do not want to touch Rust more than I have to.
  - erk__ 6y ago
    Why do you have this opinion on Rust compared to C?
  - ClumsyPilot 6y ago
    But are you the target audience - a C developer contributing, or at least considering contributing, to the Linux kernel?
- MrBuddyCasino 6y ago
  How would requiring learning Rust, which is famously difficult, be the solution to that problem?
  - xiphias2 6y ago
    Writing safe C and C++ is even much more difficult than writing Rust code (especially with many developers). And when you are writing kernel code, both safety and performance are crucial.
    - MrBuddyCasino 6y ago
      The problem seems to be to find people who do not just want to write code, but do the administrative parts: "We do not have enough maintainers. We do have a lot of people who write code, we have a fair number of maintainers, but... it's hard to find people who really look at other people's code and funnel that code upstream all the way, eventually, to my tree... It is one of the main issues we have."
      - nickez 6y ago
        Finding people willing to review rust must be much easier than finding someone willing to review c.
        xiphias2 6y ago
        Actually I think the answer is yes, as Rust is much stricter to the person who's contributing the code. If I was asked to review another person's code, I would much prefer reviewing Rust code, as I would be able to concentrate on the logic and the efficiency of the code instead of potential low level mistakes. The code smell in Rust is usually marked with ,,unsafe'', Boxing / reference counters, or dynamic behaviour, which is very easy to search for.
        verdagon 6y ago
        Is reference counters really a smell? I thought it was the main way to write Rust when the borrow checker is too strict for something you want to do. Vec + generational indices might be the other way, is that preferred over Rc?
- atq2119 6y ago
  The kernel isn't hurting for developers though. I don't see how a different programming language would help improve the ratio of maintainers vs developers.
jdub 6y ago
But you can read his response to Rust in the linked thread.
zozbot234 6y ago
Rust integrates easily with C because it's explicitly designed to fall back to the C ABI for external linkage. Whereas writing C++ with any C++-specific features (hence, any "Modern", guidelines-compliant C++ at all) brings its own bespoke ABI into the picture, that's supposed to be stable but really is not and that one can't easily interoperate with from C. That's a huge non-starter in kernel dev.
- bonzini 6y ago
  Not really, both in Rust and in C++ the C-compatible parts have to be marked explicitly as extern "C". Even the syntax is the same.
  - zozbot234 6y ago
    C compatibility is marked the same way, but it's not idiomatically used the same way in C++ and Rust. In C++, being C compatible means essentially writing C and for everything else you're expected to rely on the "not really stable" C++ ABI whereas Rust does not even try to give you a stable ABI between stuff that's not part of pretty much the same build. Despite that, you're free to mix C-like and Rustic code in the same crate because the crate is literally the translation unit in Rust.
    - bonzini 6y ago
      ABI stability doesn't matter for the kernel since it doesn't have a stable ABI either. You can write a C++ core and C wrappers for C++ classes just fine, the same as what you do in Rust.
- wwright 6y ago
  I’m a huge Rust fan, but this is a misrepresentation of C++. You can definitely use the vast majority of modern C++ features while also integrating with a C codebase (exotic control flow such as exceptions and coroutines are definitely dangerous, though).
bonzini 6y ago
> Rust has most of the same properties which prevent C++'s inclusion in-tree It does but it also has some advantages that C++ does not have.
xiphias2 6y ago
Here's Linus's answer inside the thread, which is quite positive: From: Linus Torvalds @ 2020-07-10 23:54 UTC (permalink / raw) To: Josh Triplett Cc: Christian Brauner, Nick Desaulniers, alex.gaynor, Greg KH, geofft, jbaublitz, Masahiro Yamada, Miguel Ojeda, Steven Rostedt, LKML, clang-built-linux, Kees Cook On Fri, Jul 10, 2020 at 3:59 PM Josh Triplett <josh@joshtriplett.org> wrote: > > As I recall, Greg's biggest condition for initial introduction of this > was to do the same kind of "turn this Kconfig option on and turn an > option under it off" trick that LTO uses, so that neither "make > allnoconfig" nor "make allyesconfig" would require Rust until we've had > plenty of time to experiment with it. No, please make it a "is rust available" automatic config option. The exact same way we already do the compiler versions and check for various availability of compiler flags at config time. See init/Kconfig for things like config LD_IS_LLD def_bool $(success,$(LD) -v | head -n 1 | grep -q LLD) and the rust support should be similar. Something like config RUST_IS_AVAILABLE def_bool $(success,$(RUST) ..sometest..) because I _don't_ want us to be in the situation where any new rust support isn't even build-tested by default. Quite the reverse. I'd want the first rust driver (or whatever) to be introduced in such a simple format that failures will be obvious and simple. The _worst_ situation to be in is that s (small) group of people start testing their very special situation, and do bad and crazy things because "nobody else cares, it's hidden". No, thank you.
AnssiH 6y ago
https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ https://www.theregister.com/2020/06/30/hard_to_find_linux_ma... > "C is still one of the top 10 languages," answered Torvalds. However, he said that for things "not very central to the kernel itself", like drivers, the kernel team is looking at "having interfaces to do those, for example, in Rust... I'm convinced it's going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won't be the only one."
aryonoco 6y ago
You didn't read Linus's response, did you?
hellofunk 6y ago
Correct, he must have changed his attitude on some of those features that apply to C++ as well that he previously railed against. https://news.ycombinator.com/item?id=23801076 https://news.ycombinator.com/item?id=23801076

maccam94 6y ago

I am assuming that it would work with clang-compiled[1] kernels only at first. 1: https://www.kernel.org/doc/html/latest/kbuild/llvm.html https://www.kernel.org/doc/html/latest/kbuild/llvm.html

est31 6y ago
Why would it require clang for the C components? The Rust compiler creates native libraries which can be linked to compilation units created by both clang and gcc, unless there's something special going on in the kernel that I'm not aware of.
cesarb 6y ago
Not really. Unless you want LTO, the object files generated by GCC and LLVM are compatible, and can mixed without issues.

photon12 6y ago

The thing is the kernel is kinda hurting for maintainers and opening up the path for the next generation of systems programmers (most of whom don't want to touch C any more than they have to) has to be something Linus is more likely to prioritize than in previous decades.

CommieDetector 6y ago
>next generation of systems programmers (most of whom don't want to touch C any more than they have to) Then they fail to quality as the next generation of system programmers.
bibabaloo 6y ago
> The thing is the kernel is kinda hurting for maintainers Source? AFAIK the kernel is probably one of the most, if not the most, well-funded and maintained open source projects.
- novas0x2a 6y ago
  From the horse's mouth: https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ https://www.theregister.com/2020/06/30/hard_to_find_linux_ma...
  - est31 6y ago
    > We do not have enough maintainers. We do have a lot of people who write code, we have a fair number of maintainers, but... it's hard to find people who really look at other people's code and funnel that code upstream all the way, eventually, to my tree... It is one of the main issues we have.
    - aflag 6y ago
      If I read this correctly, they have a lot of contributors, but few people willing to follow through with the code so it gets all the way up to Linus' tree. I don't see how rust would really help there.
      - ordu 6y ago
        It could be. Maybe there will not be more reviewers, but the process of reviewing could be faster. For example, in the kernel there are inline functions, which accept a constant (known at compile time) integer argument, and they make a switch or loop over that integer. The trick is to force compiler to inline function and to throw away most of switch's cases, or unroll loop completely, or make some other optimizations based on knowledge of the passed integer value. Such a functions are exported to a public kernel API sometimes. So any kernel developer could call them. It make unavoidable a mistake of a programmer, when some of those functions was called with an unknown at compile time integer value. It is not a bug as it is, code would compile and work nevertheless, code would be bigger that it could be, maybe slower, that's all. But reviewer should be finding such a misuse of API. It is just one example, linux kernel uses a lot of tricks and exposes it via APIs, reviewer must be aware of all of them and to check everything by itself. Compare it with Rust. In rust one can encode a lot more limits on the right use of an API than in C. Encode and enforce. Even when rust sometimes cannot do it, rust have nice macros, instead of C's macro-horror. So a lot of mistakes that could be made with C, could be avoided with Rust. So it would be easy to review code, it would take less time from a reviewer to review code.
Glavnokoman 6y ago
I for one do not want to touch Rust more than I have to.
- erk__ 6y ago
  Why do you have this opinion on Rust compared to C?
- ClumsyPilot 6y ago
  But are you the target audience - a C developer contributing, or at least considering contributing, to the Linux kernel?
MrBuddyCasino 6y ago
How would requiring learning Rust, which is famously difficult, be the solution to that problem?
- xiphias2 6y ago
  Writing safe C and C++ is even much more difficult than writing Rust code (especially with many developers). And when you are writing kernel code, both safety and performance are crucial.
  - MrBuddyCasino 6y ago
    The problem seems to be to find people who do not just want to write code, but do the administrative parts: "We do not have enough maintainers. We do have a lot of people who write code, we have a fair number of maintainers, but... it's hard to find people who really look at other people's code and funnel that code upstream all the way, eventually, to my tree... It is one of the main issues we have."
    - nickez 6y ago
      Finding people willing to review rust must be much easier than finding someone willing to review c.
      - xiphias2 6y ago
        Actually I think the answer is yes, as Rust is much stricter to the person who's contributing the code. If I was asked to review another person's code, I would much prefer reviewing Rust code, as I would be able to concentrate on the logic and the efficiency of the code instead of potential low level mistakes. The code smell in Rust is usually marked with ,,unsafe'', Boxing / reference counters, or dynamic behaviour, which is very easy to search for.
        verdagon 6y ago
        Is reference counters really a smell? I thought it was the main way to write Rust when the borrow checker is too strict for something you want to do. Vec + generational indices might be the other way, is that preferred over Rc?
atq2119 6y ago
The kernel isn't hurting for developers though. I don't see how a different programming language would help improve the ratio of maintainers vs developers.

jdub 6y ago

But you can read his response to Rust in the linked thread.

zozbot234 6y ago

Rust integrates easily with C because it's explicitly designed to fall back to the C ABI for external linkage. Whereas writing C++ with any C++-specific features (hence, any "Modern", guidelines-compliant C++ at all) brings its own bespoke ABI into the picture, that's supposed to be stable but really is not and that one can't easily interoperate with from C. That's a huge non-starter in kernel dev.

bonzini 6y ago
Not really, both in Rust and in C++ the C-compatible parts have to be marked explicitly as extern "C". Even the syntax is the same.
- zozbot234 6y ago
  C compatibility is marked the same way, but it's not idiomatically used the same way in C++ and Rust. In C++, being C compatible means essentially writing C and for everything else you're expected to rely on the "not really stable" C++ ABI whereas Rust does not even try to give you a stable ABI between stuff that's not part of pretty much the same build. Despite that, you're free to mix C-like and Rustic code in the same crate because the crate is literally the translation unit in Rust.
  - bonzini 6y ago
    ABI stability doesn't matter for the kernel since it doesn't have a stable ABI either. You can write a C++ core and C wrappers for C++ classes just fine, the same as what you do in Rust.
wwright 6y ago
I’m a huge Rust fan, but this is a misrepresentation of C++. You can definitely use the vast majority of modern C++ features while also integrating with a C codebase (exotic control flow such as exceptions and coroutines are definitely dangerous, though).

bonzini 6y ago

> Rust has most of the same properties which prevent C++'s inclusion in-tree It does but it also has some advantages that C++ does not have.

xiphias2 6y ago

Here's Linus's answer inside the thread, which is quite positive: From: Linus Torvalds @ 2020-07-10 23:54 UTC (permalink / raw) To: Josh Triplett Cc: Christian Brauner, Nick Desaulniers, alex.gaynor, Greg KH, geofft, jbaublitz, Masahiro Yamada, Miguel Ojeda, Steven Rostedt, LKML, clang-built-linux, Kees Cook On Fri, Jul 10, 2020 at 3:59 PM Josh Triplett <josh@joshtriplett.org> wrote: > > As I recall, Greg's biggest condition for initial introduction of this > was to do the same kind of "turn this Kconfig option on and turn an > option under it off" trick that LTO uses, so that neither "make > allnoconfig" nor "make allyesconfig" would require Rust until we've had > plenty of time to experiment with it. No, please make it a "is rust available" automatic config option. The exact same way we already do the compiler versions and check for various availability of compiler flags at config time. See init/Kconfig for things like config LD_IS_LLD def_bool $(success,$(LD) -v | head -n 1 | grep -q LLD) and the rust support should be similar. Something like config RUST_IS_AVAILABLE def_bool $(success,$(RUST) ..sometest..) because I _don't_ want us to be in the situation where any new rust support isn't even build-tested by default. Quite the reverse. I'd want the first rust driver (or whatever) to be introduced in such a simple format that failures will be obvious and simple. The _worst_ situation to be in is that s (small) group of people start testing their very special situation, and do bad and crazy things because "nobody else cares, it's hidden". No, thank you.

AnssiH 6y ago

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/ https://www.theregister.com/2020/06/30/hard_to_find_linux_ma... > "C is still one of the top 10 languages," answered Torvalds. However, he said that for things "not very central to the kernel itself", like drivers, the kernel team is looking at "having interfaces to do those, for example, in Rust... I'm convinced it's going to happen. It might not be Rust. But it is going to happen that we will have different models for writing these kinds of things, and C won't be the only one."

aryonoco 6y ago

You didn't read Linus's response, did you?

hellofunk 6y ago

Correct, he must have changed his attitude on some of those features that apply to C++ as well that he previously railed against. https://news.ycombinator.com/item?id=23801076 https://news.ycombinator.com/item?id=23801076