7 ms·

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

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 5y ago
He doesn't mention that it's an alpha feature
- CodeWriter23 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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)
    - CodeWriter23 5y ago
      I think the gist of what he is saying is typical application programming patterns like crash on exception, gc, etc. are not a good fit for kernel programming. And I agree. Handle the request or return an error and let higher level code handle the error processing.
darthrupert 5y ago
> Personally, I'm very excited about Rust in the kernel. Why?
- gpm 5y 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 5y 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 5y 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.

Ceezy 5y ago

He doesn't mention that it's an alpha feature

CodeWriter23 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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)
  - CodeWriter23 5y ago
    I think the gist of what he is saying is typical application programming patterns like crash on exception, gc, etc. are not a good fit for kernel programming. And I agree. Handle the request or return an error and let higher level code handle the error processing.

darthrupert 5y ago

> Personally, I'm very excited about Rust in the kernel. Why?

gpm 5y 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 5y 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 5y 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.