A prediction with no data to support it

Posted Feb 26, 2025 3:07 UTC (Wed) by dralley (subscriber, #143766)
In reply to: A prediction with no data to support it by dowdle
Parent article: A change in maintenance for the kernel's DMA-mapping layer

A pretty significant majority of Linux code is in drivers rather than the core kernel, and I would bet that's also where most of the churn is in terms of new patches. You also don't really need as much experience in the kernel to write a driver, than, say, trying to overhaul some subsystem, and there's a lot more sandboxes to play in. So I would think it's a pretty good way to train up new future kernel developers.

All this is to say that it's not a bad bet long-term, but also it's not actually necessary to touch the core kernel to make a big dent in those 40 million lines. But if the pipeline for new kernel developers is predominated by Rust, then yes it probably will make it's way into the kernel over time.

A prediction with no data to support it

Posted Feb 26, 2025 9:11 UTC (Wed) by taladar (subscriber, #68407) [Link]

I can't speak for other Rust developers but I wouldn't even consider writing a driver in the kernel unless all the dependencies for drivers of that type have Rust bindings or maintainers open to adding them.

So I would really expect the core subsystems to get bindings (or Rust replacements once it is clear that Rust is necessary to build the kernel anyway) first before the majority of existing drivers are replaced by Rust ones, especially considering how the Rust community tends to lean towards thinking things through and doing things in the right order with the RFC process for language changes.