Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20

[phoronix]

Phoronix: Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20

Speaking this morning at The Linux Foundation's Open-Source Summit, Linus Torvalds talked up the possibilities of Rust within the Linux kernel and that it could be landing quite soon -- possibly even for the next kernel cycle...

https://www.phoronix.com/scan.php?pa...-5.20-Possible

[archkde]

Rust support being such an exciting feature and judging by the past timing, I think the first kernel with merged Rust support should be called 6.0.

[mcloud]

Rust support being such an exciting feature and judging by the past timing, I think the first kernel with merged Rust support should be called 6.0.

I would think 6.0 should be the one that mandates rust support. That by itself would be a "breaking change" needing a new major version

[bug77]

I'm surprised things are moving so fast. gg

archkde If there was Rust in the kernel, yes, that would make sense. But we're only talking about using Rust for some drivers (which I think is a sensible, cautious approach).

[uid313]

I like Rust but it sucks that it doesn't yet have async functions in traits. 😭️
It also sucks that async is shattered islands with non-interoperable packages that depend on a specific async runtimes. 😭️

[TumultuousUnicorn]

I think the first kernel with merged Rust support should be called 6.0.

Rust or no rust, I think "5.20" may be "6.0", as Linus is not a big fan of "large numbers". As a reminder:
2.6.39 -> 3.0
3.19 -> 4.0
4.20 -> 5.0

[binarybanana]

Nice. I've done some kernel hacking before, but I'm always anxious about any unforeseen side effects that might cause random breakage. Rust's type system would help with confidence at least. I wonder how quickly it's going to be picked up by drivers or the more interesting subsystems (DRM/KMS, netfilter, etc.). Writing ip/nftables modules in Rust would be amazing!

I like Rust but it sucks that it doesn't yet have async functions in traits. 😭️
It also sucks that async is shattered islands with non-interoperable packages that depend on a specific async runtimes. 😭️

The lack of language support for HKTs is also frustrating. You can kinda hack them in and somehow works, but it's far from ideal. I was hoping the likes of Amazon and Microsoft getting involved would speed things up, but sadly it seems a bit like Rust development has somewhat stagnated.

[archkde]

I'm surprised things are moving so fast. gg

archkde If there was Rust in the kernel, yes, that would make sense. But we're only talking about using Rust for some drivers (which I think is a sensible, cautious approach).

Still it's a very large paradigm shift. All kernel code (which includes drivers btw, Linux is a monolithic kernel) was only permitted to use C for the entire history of Linux. The release where core code is oxidized can then be called 7.0

[archkde]

I would think 6.0 should be the one that mandates rust support. That by itself would be a "breaking change" needing a new major version

Linux does not use semantic versioning. The major version changes when the minor gets too big for Linus' taste. All releases may break the kernel ABI, and none may break the userspace ABI.

[archkde]

I like Rust but it sucks that it doesn't yet have async functions in traits. 😭️
It also sucks that async is shattered islands with non-interoperable packages that depend on a specific async runtimes. 😭️

Use the async-trait crate for the first issue. The second issue is a bit annoying, but I think things settle on tokio nowadays.