Rustaceans at the border

Linux doesn't really run on microcontrollers at all - the point is that the technical constraints for kernel software on a regular desktop CPU are very similar to the constraints for application software on a microcontroller, in contrast to the very different constraints for application software on desktop CPUs. (E.g. they can't crash and expect an OS to clean up after them, so they need to think more carefully about handling heap allocation failures, and/or avoid using the heap entirely. They typically have small stacks, so they need to avoid large stack allocations or recursion. They need to handle interrupts, which are a peculiar kind of concurrency where you can't use normal mutexes. There's no pthreads. They often can't use an FPU. Code size is important. Etc.)

So there's a good chance that libraries designed for microcontroller applications will be technically suitable for the Linux kernel. Of course they'd still need to be code-reviewed and maybe adapted slightly for the specific environment they're being used in, and there's social questions about who will maintain the code and what their priorities are, but the same applies to new code that's written exclusively for Linux. Starting from an existing well-designed well-tested library should achieve the same quality with less work than starting from scratch.

Rust's no_std doesn't mean a library is necessarily suitable for microcontrollers/kernels, but it does mean it avoids some common features that would make it definitely unsuitable, so it seems a good way to filter libraries before reviewing them in more depth.