5 ms·

> I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects, that it isn't. That's

> I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects, that it isn't. That's not what this is about, so even though you aren't tired of posting this, I'm not sure it's warranted. This is about the kernel supporting other languages in select places where it makes sense, such as kernel modules, where there's already an API in place to conform to. It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations. > I won't get tired of repeating the same comment in every topic that suggests Rust to be a great replacement of C in existing projects, that it isn't. Nobody is giving up on existing C interfaces. They are simply making sure those interfaces are not actively hostile to languages that aren't C by nature of how they are implemented in C. To be clear, the "kmalloc_for_rust" was mentioned as one possible way forward. Another would be a more advanced Rust bindgen tool that can determine how to deal with it automatically. Neither affect ATS, based on your description (although a "kmalloc_for_extern" might generally help any non-C language, which would probably be beneficial). If ATS doesn't require any changes to C to interoperate with it, this whole announcement should have zero impact on ATS, other than possibly making it easier to get an ATS module in-kernel since they're trying to make it easier in general for non-C modules. You can treat this as a zero-sum gain, where Rust or Go's gain is ATS' loss, in which case you might as well pack up your bags now, since the writing is on the wall based on publicity, or you can treat it as a rising tide raises all boats type situation, where more general acceptance of alternatives to C is still beneficial to ATS actually being allowed in-kernel, even if it doesn't play exactly to ATS' strengths. I know which one I would put my money behind as being a better strategy in the end.

ghostwriter 6y ago
> It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: > They focused on security concerns, citing work showing that around two-thirds of the kernel vulnerabilities that were assigned CVEs in both Android and Ubuntu stem from memory-safety issues. Rust, in principle, can completely avoid this error class via safer APIs enabled by its type system and borrow checker. So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) and without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust".
- bsder 6y ago
  > So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) The answer to this question appears to be: no. Memory errors sit somewhere around 2/3 to 3/4 of errors irrespective of codebase when C is involved (this has been consistent in things like the Linux kernel as well as the Windows codebase). C++ hasn't seemed to have changed that, either. Remember, Rust IS Mozilla's answer to this question. > without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust". The requirement to do that is pointing out the that kernel API is poor and is too intimately tied to the build chain. We have seen this before--when Linux got ported to Alpha, for example. The point is to fix the API so that more languages than just Rust can be used. I suspect that more "system programming" languages may appear once Rust does the difficult groundwork of breaking this kind of intimate toolchain dependence. As things currently stand, why develop a system programming language given that no one will ever use it?
  - einpoklum 6y ago
    > C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.
    - bsder 6y ago
      > of course people can write unsafe C++ if they want to. The problem is knowing the safe subset of the language requires continuous study and deep understanding. It also has changed with time. I used to have a bookshelf in order to understand C++. I suspect that has not changed. I do not need a bookshelf to understand the "safe" subset of Rust.
      - 6y ago
kazinator 6y ago
> They are simply making sure those interfaces are not actively hostile to languages that aren't C ... I.e. not actively small and fast, like an OS should be.
- geofft 6y ago
  1. This claim needs benchmarking. 2. Linux is already moving in the direction of having easier-to-use internal interface over small, fast, and tricky ones. For kmalloc in particular, the memory management docs https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html https://www.kernel.org/doc/html/latest/core-api/memory-alloc... recommends kzalloc (which zeroes data) and suggests a function called kvmalloc which calls either kmalloc or vmalloc depending on the size of the allocation. It unconditionally recommends kvfree (which handles alloations from either kmalloc or vmalloc) instead of asking you to use kfree or vfree as appropriate. 3. In this particular case, kmalloc is inlined because it calls krealloc(NULL, ...). This could almost certainly be equivalently handled by inlining the other side of it. (Again, benchmarking.) 4. LTO is a thing.
  - deleted 6y ago
    [deleted]

ghostwriter 6y ago

> It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: > They focused on security concerns, citing work showing that around two-thirds of the kernel vulnerabilities that were assigned CVEs in both Android and Ubuntu stem from memory-safety issues. Rust, in principle, can completely avoid this error class via safer APIs enabled by its type system and borrow checker. So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) and without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust".

bsder 6y ago
> So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) The answer to this question appears to be: no. Memory errors sit somewhere around 2/3 to 3/4 of errors irrespective of codebase when C is involved (this has been consistent in things like the Linux kernel as well as the Windows codebase). C++ hasn't seemed to have changed that, either. Remember, Rust IS Mozilla's answer to this question. > without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust". The requirement to do that is pointing out the that kernel API is poor and is too intimately tied to the build chain. We have seen this before--when Linux got ported to Alpha, for example. The point is to fix the API so that more languages than just Rust can be used. I suspect that more "system programming" languages may appear once Rust does the difficult groundwork of breaking this kind of intimate toolchain dependence. As things currently stand, why develop a system programming language given that no one will ever use it?
- einpoklum 6y ago
  > C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.
  - bsder 6y ago
    > of course people can write unsafe C++ if they want to. The problem is knowing the safe subset of the language requires continuous study and deep understanding. It also has changed with time. I used to have a bookshelf in order to understand C++. I suspect that has not changed. I do not need a bookshelf to understand the "safe" subset of Rust.
    - 6y ago

kazinator 6y ago

> They are simply making sure those interfaces are not actively hostile to languages that aren't C ... I.e. not actively small and fast, like an OS should be.

geofft 6y ago
1. This claim needs benchmarking. 2. Linux is already moving in the direction of having easier-to-use internal interface over small, fast, and tricky ones. For kmalloc in particular, the memory management docs https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html https://www.kernel.org/doc/html/latest/core-api/memory-alloc... recommends kzalloc (which zeroes data) and suggests a function called kvmalloc which calls either kmalloc or vmalloc depending on the size of the allocation. It unconditionally recommends kvfree (which handles alloations from either kmalloc or vmalloc) instead of asking you to use kfree or vfree as appropriate. 3. In this particular case, kmalloc is inlined because it calls krealloc(NULL, ...). This could almost certainly be equivalently handled by inlining the other side of it. (Again, benchmarking.) 4. LTO is a thing.
- deleted 6y ago
  [deleted]