Good point, I note that realtime preemption has been in the works for more than twenty years, but (surprisingly) still isn't in mainline. On the other hand it's widely used and available and has caused lots of changes upstream already.
https://cdn.kernel.org/pub/linux/kernel/projects/rt/6.11/
And this is the only way you'll get large changes like these into the kernel: slow and steady.
Why exactly?
Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested. Besides, that would also take ages: it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.
Yeah, I don't think you know this.
As I understand it, there have been schedulers written in Rust for Linux already which are faster in specific use cases.
> Now, you could take these stacks from the Linux kernel and rewrite them in Rust, but that's not what Drew has suggested.
As I understand it, Drew that's exactly what he suggested? He didn't say go write a new system. He said go write an ABI compatible system. It's hard for me to imagine he meant "Write an ABI compatible system with wildly different semantics."
> Besides, that would also take ages:
Agreed, and that's what makes his suggestion mostly ridiculous.
> it's a lot of very complicated code, and a lot of it cannot just be transferred to Rust without it becoming unsafe, making the whole point of having a kernel in Rust moot.
I think this passage confuses a few key concepts. First, I'm not really certain how much unsafe a scheduler or a networking stack would have to use. My guess is not that much. Do you have some reason to believe it would have to use an inordinate amount of unsafe? Next, simply using unsafe does not moot the safety argument for using Rust. I've said this about a billion times, but once more: unsafe constrain memory safety to a small enough area that one can reason about it.