Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Everytime features are mentioned it makes me go: "it's all fun and games until someone puts tokio into the kernel", better yet if rust becomes complete enough and someone makes a direct composition renderer we could have entire applications that run entirely in the kernel which could be... interesting.


It's trivial to implement an async runtime in the kernel. The kernel's workqueue is already essentially a runtime.


I was about to take offence at the use of “trivial” in this context. But then I noticed your handle, lol. You have the license to say that, thanks for your contributions!


It never made it into upstream Linux, but there is already a sample implementation that Wedson wrote in 2022: https://github.com/Rust-for-Linux/linux/pull/798


Won't that be an eager runtime though? Breaking Rust's assumption that futures do nothing until polled? Unless you don't submit it to the queue until the poll call, I guess


It won't be different from Tokio. When you pass a future to tokio::spawn, that will also eagerly execute the future right away.


I'm not sure if you're joking, but if not this is a fundamental misunderstanding of how Rust (and C) are used in the kernel.

Much like how you don't have the C stdlib when writing kernel code, Rust is used with the no_std option. You do not use cargo and do not have access to crates.

You'd likely have to rewrite half of tokio to use kernel level abstractions for things like sockets and everything else that interacts with the OS.


that's the joke. I've made most of c runtime work in the windows kernel before though.


Yeah that sounds a lot like nolibc which is basically a libc-ish shim that's in the Linux kernel tree.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: