4 ms·

Just to turn this discussion towards the practical aspect: does anyone know if a concrete effort has been made to sound out Torvalds and the other senior kernel

Just to turn this discussion towards the practical aspect: does anyone know if a concrete effort has been made to sound out Torvalds and the other senior kernel devs about accepting Rust into the kernel? I would imagine that initially as PoC one can start by implementing a simple module... obviously a small portion of the Rust stdlib and runtime needs to be ported and of course rustc needs to be integrated into the kernel toolchain... Perhaps someone has done it privately (i.e., without attempting to submit patches back to source)?

steeleduncan 9y ago
In [1] (from 2016) he says I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting) I think what he is saying is that rewriting c->(e.g.) rust doesn't improve make progress on any of the design problems in the linux kernel. In [2] (2013) he expands on that, essentially explaining how well C maps to machine instructions, and how that helps optimise the kernel. Personally I think Rust maps very well to machine code, and although it doesn't solve design problems, I do think it saves a lot of time debugging the security flaws and bugs that can result from memory bugs. [1] https://www.infoworld.com/article/3109150/linux/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux/linux-at-25-... [2] https://www.reddit.com/r/programming/comments/1t0gfy/linus_torvalds_on_the_question_if_there_is_a/ https://www.reddit.com/r/programming/comments/1t0gfy/linus_t...
- Santosh83 9y ago
  I tend to agree with his point that you may perhaps not solve design and driver problems just changing language, but can anyone dispute that a memory-safe language can at least help eliminate routine programming pitfalls like off-by-one, null deferences, double-free and so on? And these are the types of innocuous and inadvertent errors that are exploited by black-hats, sometimes with costly consequences. I don't see a strong argument against a memory-safe language, although granted it won't solve architectural and hardware issues. Perhaps the effort to support, say Rust, in the kernel is just not worth the trade-off at this point? Perhaps no one has taken on the mantle for doing so? But I can't see how one can categorically argue against it...
- agumonkey 9y ago
  maybe a different approach to hardware programming, some kind of safer and higher abstraction system/language to improve quality and reduce effort ?
empath75 9y ago
Don’t think it’ll ever happen. More likely something like redox will get to the point that it’s production-ready and people will just stop using Linux. I don’t think it’s far off, at least for vms, tbh.
- sixbrx 9y ago
  > at least for vms Yeah that may be a really good upside to VMs, that they enable new OSs to have a more level playing field with the established OSs. Letting the VM layer handle all the messy details of real hardware.
slrz 9y ago
> Just to turn this discussion towards the practical aspect: does anyone know if a concrete effort has been made to sound out Torvalds and the other senior kernel devs about accepting Rust into the kernel? This is not how things work. You don't arrive at changes like this by out-talking Linus. Talk is cheap and Linus is opinionated. You need to demonstrate that what you want to do is worthwile, i.e. is not only feasible but also provides a payoff that carries the weight of what you're proposing. You also need to be fiercely committed to your idea and to making it happen inside mainline Linux. In other words, show me the code (and maintain it out-of-tree for some time, tracking upstream changes and gathering support from other developers).

steeleduncan 9y ago

In [1] (from 2016) he says I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting) I think what he is saying is that rewriting c->(e.g.) rust doesn't improve make progress on any of the design problems in the linux kernel. In [2] (2013) he expands on that, essentially explaining how well C maps to machine instructions, and how that helps optimise the kernel. Personally I think Rust maps very well to machine code, and although it doesn't solve design problems, I do think it saves a lot of time debugging the security flaws and bugs that can result from memory bugs. [1] https://www.infoworld.com/article/3109150/linux/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux/linux-at-25-... [2] https://www.reddit.com/r/programming/comments/1t0gfy/linus_torvalds_on_the_question_if_there_is_a/ https://www.reddit.com/r/programming/comments/1t0gfy/linus_t...

Santosh83 9y ago
I tend to agree with his point that you may perhaps not solve design and driver problems just changing language, but can anyone dispute that a memory-safe language can at least help eliminate routine programming pitfalls like off-by-one, null deferences, double-free and so on? And these are the types of innocuous and inadvertent errors that are exploited by black-hats, sometimes with costly consequences. I don't see a strong argument against a memory-safe language, although granted it won't solve architectural and hardware issues. Perhaps the effort to support, say Rust, in the kernel is just not worth the trade-off at this point? Perhaps no one has taken on the mantle for doing so? But I can't see how one can categorically argue against it...
agumonkey 9y ago
maybe a different approach to hardware programming, some kind of safer and higher abstraction system/language to improve quality and reduce effort ?

empath75 9y ago

Don’t think it’ll ever happen. More likely something like redox will get to the point that it’s production-ready and people will just stop using Linux. I don’t think it’s far off, at least for vms, tbh.

sixbrx 9y ago
> at least for vms Yeah that may be a really good upside to VMs, that they enable new OSs to have a more level playing field with the established OSs. Letting the VM layer handle all the messy details of real hardware.

slrz 9y ago

> Just to turn this discussion towards the practical aspect: does anyone know if a concrete effort has been made to sound out Torvalds and the other senior kernel devs about accepting Rust into the kernel? This is not how things work. You don't arrive at changes like this by out-talking Linus. Talk is cheap and Linus is opinionated. You need to demonstrate that what you want to do is worthwile, i.e. is not only feasible but also provides a payoff that carries the weight of what you're proposing. You also need to be fiercely committed to your idea and to making it happen inside mainline Linux. In other words, show me the code (and maintain it out-of-tree for some time, tracking upstream changes and gathering support from other developers).