Rust Code Updated For The Linux Kernel - Networking & Async Support Started

[phoronix]

Phoronix: Rust Code Updated For The Linux Kernel - Networking & Async Support Started

Making for an exciting Saturday morning, Miguel Ojeda has posted the latest patch series plumbing Rust language support into the Linux kernel. The "Rust for the Linux kernel" patches are now up to their sixth version for adding the necessary infrastructure for this second, optional language to the kernel plus continuing to add more sample code / basic functionality for showing off use of this memory-safety-focused language for kernel purposes...

https://www.phoronix.com/scan.php?page=news_item&px=Rust-v6-For-Linux-Kernel

[jacob]

Having "Async" supported within the kernel would certainly make it a very interesting proposition.

[bachchain]

Having "Async" supported within the kernel would certainly make it a very interesting proposition.

I'm interested in what they're going to do about the executor. I somehow doubt the kernel team will be too keen on modules pulling in Tokio

[stormcrow]

I'm interested in what they're going to do about the executor. I somehow doubt the kernel team will be too keen on modules pulling in Tokio

Followed by an attack by Godzilla.

[skeevy420]

Followed by an attack by Godzilla.

With a purposeful grimace and a terrible sound
He pulls the spitting high tension wires down

[NobodyXu]

I'm interested in what they're going to do about the executor. I somehow doubt the kernel team will be too keen on modules pulling in Tokio

It is impossible to use tokio in kernel space, as tokio uses syscalls provided by the kernel.

The kernel will likely have its own executor, probably plug into the kernel's own async infrastructure.

[mmstick]

I'm interested in what they're going to do about the executor. I somehow doubt the kernel team will be too keen on modules pulling in Tokio

The same thing that embedded programmers are already doing with Rust. There's already multiple async executors available for embedded platforms, just as there are multiple userspace executors, and multiple Linux-exclusive userspace executors. Write your own executor that is based on the functionality of the platform you're targeting. Whether that's making internal kernel calls directly or leveraging an existing C API. Rust futures are just state machines. They'll run on any executor.

[slanterns]

I'm interested in what they're going to do about the executor. I somehow doubt the kernel team will be too keen on modules pulling in Tokio

They have implemented their own executed `kasync` https://github.com/wedsonaf/linux/bl...nc/executor.rs

[kylew77]

I worry if Linux releases graphics drivers in Rust that all the down source users of the code like all the *BSDs and even niche operating systems like Haiku will have to somehow shoehorn Rust into their OS too. That isn't a problem for AMD64 or AArch64 but is a problem for OpenBSD and NetBSD that support MIPS and SPARC and SPARC64 that don't have Rust support for those architectures. I guess that isn't a problem for say the Intel integrated graphics stack that is only found on AMD64 CPUs but what about discrete graphics cards, network cards, etc?

[dragonn]

That isn't a problem for AMD64 or AArch64 but is a problem for OpenBSD and NetBSD that support MIPS and SPARC and SPARC64 that don't have Rust support for those architectures. I guess that isn't a problem for say the Intel integrated graphics stack that is only found on AMD64 CPUs but what about discrete graphics cards, network cards, etc?

I don't get that point, it is not like it is impossible to add new targets in Rust... if demand will be for a new target I am pretty sure we will get one.
Mips is already in Tier 2 with Host Tools https://doc.rust-lang.org/nightly/ru...ith-host-tools and Sparc is in Tier 2 without them.