9 ms·

The title is slightly misleading, and so is Linus' response here. This RFC never claimed to be in shape to be immediately mergeable into the mainline kernel as-

The title is slightly misleading, and so is Linus' response here. This RFC never claimed to be in shape to be immediately mergeable into the mainline kernel as-is. Miguel (the author of the patch) has replied to this mail (and in other places in the thread) that the Rust alloc() is currently called only as a temporary measure to speed up development, and all panic() calls from allocation failures are just as temporary. This is all because the Rust code that hooks into the kernel memory allocation functions is not yet usable. The main point of this RFC is that "the [in-kernel Rust] support is good enough that prototyping modules can start today." There's no point in making long arguments about alpha-quality design shortcuts on an alpha-quality prototype that are also explicitly mentioned by the patch authors to be of alpha quality. See e.g. https://lkml.org/lkml/2021/4/14/1130 https://lkml.org/lkml/2021/4/14/1130 and https://lkml.org/lkml/2021/4/14/1023 https://lkml.org/lkml/2021/4/14/1023 EDIT: Thanks for the child comments; it seems that Linus is simply not aware of all the specifics and is asking for more information and/or decided to look at the code before reading the full mail thread.

caust1c 6y ago
I don't really see anything misleading in the post. Linus says that the comments/responses are from a position of ignorance and it seems like he's just seeking understanding. If anything is misleading it's linking to random emails in lkml without context. :-P (Maybe that's what you were getting at). Personally, I'm very excited about Rust in the kernel.
- Ceezy 6y ago
  He doesn't mention that it's an alpha feature
  - CodeWriter23 6y ago
    There are literally millions of things he didn’t say. He did however express a requirement for acceptance. That’s the message, if you want this in the kernel, it has to never call panic() at run time. Why? Because kernel crashes are unacceptable for the types of deployment Linux is used for.
    - UtherII 6y ago
      I not sure he mean never panic at runtime. I think there are good reason to panic at runtime if you care about safety a buffer overflow is a good reason for instance. But a memory allocation failure is clearly not a good reason.
      - OskarS 6y ago
        It would be hard for him to be clearer: > With the main point of Rust being safety, there is no way I will ever accept "panic dynamically" (whether due to out-of-memory or due to anything else - I also reacted to the "floating point use causes dynamic panics") as a feature in the Rust model.
        remexre 6y ago
        WRT floating-point, worth noting for those who haven't read the patches: - Kernels generally don't want to use floating-point, because saving and restoring the floating-point registers is fairly expensive. - Without some pretty aggressive hacking, it's not possible to remove floating-point support from Rust. - What you /can/ do (and what these patches do) is replace all the floating-point builtins with kernel panics. - This obviously sucks versus actually removing the floating-point, but this is an RFC.
        myrrlyn 6y ago
        There is some work in progress to make it easier to tell Cargo to build `core`/`alloc`, which in turn would allow projects to maintain patches atop them like disabling floating-point or oom-panicking APIs entirely. I suspect that this effort will get a great deal of motivation from being a kernel requirement
      - dnautics 6y ago
        Out of memory allocation panic is absolutely not acceptable in a kernel, and even less so when you're linux (which does some sneaky memory overcommit things)
      - 6y ago
- darthrupert 6y ago
  > Personally, I'm very excited about Rust in the kernel. Why?
  - gpm 6y ago
    Speaking for myself and not the person you replied to - It would make me 10x more likely to work on the kernel, just because I enjoy programming in rust more than I enjoy programming in C. (At least given my current employment, any kernel contributions would be on my own time) - It would give me more faith in the security of other code people are contributing, things like binder in C strike me as pretty scary components of android from a security perspective, I'm much more comfortable running the same thing written in Rust. - I think it would generally reduce the number of kernel bugs in components written in it. Kernel bugs are rare, but and very frustrating when you encounter them. - I think it would increase the general productivity in kernel development. A better kernel helps everyone out. - It acts as validation for rust as a language. Obviously the kernel people shouldn't care about this in the slightest and it's not an argument for including it. However if it is included for other reasons (see above), it does help me argue that "rust would be a good fit for x" in other situations.
    - caslon 6y ago
      >- I think it would increase the general productivity in kernel development. A better kernel helps everyone out. Don't you think the massive increase in compilation time would negate any productivity gains and probably decrease productivity overall?
      - gpm 6y ago
        No, because - I don't think it will be massive. - I especially don't think it will be that large for incremental builds, which is the main thing that matters. (But I'm not involved in this project, so I don't actually know how incremental the builds are...) - My experience is that the vast majority of programming time is spent fixing mistakes, not compiling. Rust reduces the amount of time spent fixing mistakes a lot more than it increases time spent compiling. - Rust moves many errors early in the compilation process (instead of when you try and test your code), which reduces iteration time instead of increasing it. I'm not involved in this project, but I imagine it's at a point where you could get some numbers for the fixed overhead that adding rust adds to the compile times. I'd be interested in seeing those numbers.
darkwater 6y ago
But looks like Linus doesn't know the specifics, he is asking for more info while at the same time making already clear enough that if his concern cannot be addressed than there is no point working on the Rust integration until it is fixed.
karmakaze 6y ago
Anyone thinking that Rust is ready to be used in the kernel, just read the post first. It is very short. Then read these comments to look for what you need answered. For me, the main point is Can Rust be written to guarantee that no oom (or other hard fail 128-bit math) panic occurs that is not under control of the written code? I want the answer to be yes and also want to see how (which isn't far off from what Linus is asking).
- nickez 6y ago
  Yes, don't use the std lib (or more specifically the alloc crate) and don't use types like floats and u128.
  - bonzini 6y ago
    Is it possible to use Box (which is special cased in many places in the language and thus cannot be replaced, unlike for example Arc) without the alloc crate?
    - myrrlyn 6y ago
      a replacement to `alloc` would define a `Box` structure and tag it as `#[lang = "box"]` but not define any crashy APIs. this would accomplish the goal, but is an annoying patch that `alloc` should work to obviate upstream
- gpm 6y ago
  > Can Rust be written to guarantee that no oom Yes, easily, OOM is entirely a library created concept in rust, just don't use the standard library (or the `alloc` susbset of the standard library) and you don't have OOMs... > (or other hard fail 128-bit math) 128 bit math, and floats, need to be avoided by just "not using them", the same as for floats in C code in the kernel...
  - mywittyname 6y ago
    What's the issues with floats? Everyone is casually talking about this issue like it's common knowledge. Online searches of floating point panics doesn't really bring up any information beside bug reports. Is it something about floating point operations not actually being fixed-sized?

caust1c 6y ago

I don't really see anything misleading in the post. Linus says that the comments/responses are from a position of ignorance and it seems like he's just seeking understanding. If anything is misleading it's linking to random emails in lkml without context. :-P (Maybe that's what you were getting at). Personally, I'm very excited about Rust in the kernel.

Ceezy 6y ago
He doesn't mention that it's an alpha feature
- CodeWriter23 6y ago
  There are literally millions of things he didn’t say. He did however express a requirement for acceptance. That’s the message, if you want this in the kernel, it has to never call panic() at run time. Why? Because kernel crashes are unacceptable for the types of deployment Linux is used for.
  - UtherII 6y ago
    I not sure he mean never panic at runtime. I think there are good reason to panic at runtime if you care about safety a buffer overflow is a good reason for instance. But a memory allocation failure is clearly not a good reason.
    - OskarS 6y ago
      It would be hard for him to be clearer: > With the main point of Rust being safety, there is no way I will ever accept "panic dynamically" (whether due to out-of-memory or due to anything else - I also reacted to the "floating point use causes dynamic panics") as a feature in the Rust model.
      - remexre 6y ago
        WRT floating-point, worth noting for those who haven't read the patches: - Kernels generally don't want to use floating-point, because saving and restoring the floating-point registers is fairly expensive. - Without some pretty aggressive hacking, it's not possible to remove floating-point support from Rust. - What you /can/ do (and what these patches do) is replace all the floating-point builtins with kernel panics. - This obviously sucks versus actually removing the floating-point, but this is an RFC.
        myrrlyn 6y ago
        There is some work in progress to make it easier to tell Cargo to build `core`/`alloc`, which in turn would allow projects to maintain patches atop them like disabling floating-point or oom-panicking APIs entirely. I suspect that this effort will get a great deal of motivation from being a kernel requirement
    - dnautics 6y ago
      Out of memory allocation panic is absolutely not acceptable in a kernel, and even less so when you're linux (which does some sneaky memory overcommit things)
    - 6y ago
darthrupert 6y ago
> Personally, I'm very excited about Rust in the kernel. Why?
- gpm 6y ago
  Speaking for myself and not the person you replied to - It would make me 10x more likely to work on the kernel, just because I enjoy programming in rust more than I enjoy programming in C. (At least given my current employment, any kernel contributions would be on my own time) - It would give me more faith in the security of other code people are contributing, things like binder in C strike me as pretty scary components of android from a security perspective, I'm much more comfortable running the same thing written in Rust. - I think it would generally reduce the number of kernel bugs in components written in it. Kernel bugs are rare, but and very frustrating when you encounter them. - I think it would increase the general productivity in kernel development. A better kernel helps everyone out. - It acts as validation for rust as a language. Obviously the kernel people shouldn't care about this in the slightest and it's not an argument for including it. However if it is included for other reasons (see above), it does help me argue that "rust would be a good fit for x" in other situations.
  - caslon 6y ago
    >- I think it would increase the general productivity in kernel development. A better kernel helps everyone out. Don't you think the massive increase in compilation time would negate any productivity gains and probably decrease productivity overall?
    - gpm 6y ago
      No, because - I don't think it will be massive. - I especially don't think it will be that large for incremental builds, which is the main thing that matters. (But I'm not involved in this project, so I don't actually know how incremental the builds are...) - My experience is that the vast majority of programming time is spent fixing mistakes, not compiling. Rust reduces the amount of time spent fixing mistakes a lot more than it increases time spent compiling. - Rust moves many errors early in the compilation process (instead of when you try and test your code), which reduces iteration time instead of increasing it. I'm not involved in this project, but I imagine it's at a point where you could get some numbers for the fixed overhead that adding rust adds to the compile times. I'd be interested in seeing those numbers.

darkwater 6y ago

But looks like Linus doesn't know the specifics, he is asking for more info while at the same time making already clear enough that if his concern cannot be addressed than there is no point working on the Rust integration until it is fixed.

karmakaze 6y ago

Anyone thinking that Rust is ready to be used in the kernel, just read the post first. It is very short. Then read these comments to look for what you need answered. For me, the main point is Can Rust be written to guarantee that no oom (or other hard fail 128-bit math) panic occurs that is not under control of the written code? I want the answer to be yes and also want to see how (which isn't far off from what Linus is asking).

nickez 6y ago
Yes, don't use the std lib (or more specifically the alloc crate) and don't use types like floats and u128.
- bonzini 6y ago
  Is it possible to use Box (which is special cased in many places in the language and thus cannot be replaced, unlike for example Arc) without the alloc crate?
  - myrrlyn 6y ago
    a replacement to `alloc` would define a `Box` structure and tag it as `#[lang = "box"]` but not define any crashy APIs. this would accomplish the goal, but is an annoying patch that `alloc` should work to obviate upstream
gpm 6y ago
> Can Rust be written to guarantee that no oom Yes, easily, OOM is entirely a library created concept in rust, just don't use the standard library (or the `alloc` susbset of the standard library) and you don't have OOMs... > (or other hard fail 128-bit math) 128 bit math, and floats, need to be avoided by just "not using them", the same as for floats in C code in the kernel...
- mywittyname 6y ago
  What's the issues with floats? Everyone is casually talking about this issue like it's common knowledge. Online searches of floating point panics doesn't really bring up any information beside bug reports. Is it something about floating point operations not actually being fixed-sized?