|
|
Log in / Subscribe / Register

More Rust concepts for the kernel

More Rust concepts for the kernel

Posted Sep 23, 2021 19:48 UTC (Thu) by tialaramex (subscriber, #21167)
In reply to: More Rust concepts for the kernel by cpitrat
Parent article: More Rust concepts for the kernel

Certainly it's easy to imagine that if writing safe Rust can produce a working kernel driver for relatively simple hardware that's a member of an existing class (e.g yet another serial driver, or a DVB decoder device), there are going to be some people who are pretty mediocre programmers and whose C programming in particular isn't up to this job, but can write an acceptable Rust driver.

In my opinion the best targets are cases where multiple distinct hardware implementations exist without any good reason. Think entry-level PCI network cards in the late 1990s. There's no reason for so many different vendors to make a 100Mbps PCI Ethernet card that has essentially the same features as the competitors but requires its own driver, but that's what happened, and you can imagine that there's nothing interesting (potentially requiring unsafe and deep kernel knowledge or new subsystem code) in the NE2k driver compared to the 3Com one so that the work to make the 19th and 20th of these drivers is not actually the application of arcane wisdom kernel programmers might pride themselves in, but mostly rote work copying from manufacturer data sheets and a little bit of "suck it and see" when the data sheet is needlessly ambiguous. Rust is going to make that practical for patient non-experts whose sole advantage over the existing Linux maintainers is that they own the hardware they're writing a driver for so they can iterate over the "suck it and see" aspects very rapidly.


to post comments

More Rust concepts for the kernel

Posted Sep 23, 2021 20:34 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

> mostly rote work copying from manufacturer data sheets and a little bit of "suck it and see" when the data sheet is needlessly ambiguous.

Though I'm not sure the data sheet for the NatSemi DP83820 mentions the thing where the transmitter interrupt is unreliable.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds