> LLVM does not target all of the architectures that Linux supports and just because a target is supported in LLVM does not mean that the kernel will build or work without any issues.
You can compile most common Linux kernel targets with clang, but the kernel was historically optimized with GCC in mind, so I believe there are still size and speed impacts from using LLVM.
Not to mention plain ol' inertia. The vast majority of people compiling the kernel are using GCC. Switching to a different toolchain or maintaining two toolchains (assuming there are no subtle ABI issues between a GCC kernel and LLVM driver) isn't necessarily trivial, and requiring that just to build a single driver might rub some people the wrong way. That's not a _problem_ with LLVM, but it is an inconvenience.
ARM seems to have pretty thoroughly won the category of “embedded targets that are capable enough to run Linux”, though. Other than ARM and (presumably in the future) RISC-V, what other architectures are still relevant for new embedded designs that would run Linux?
Obviously there is still significantly more diversity at the low end of the embedded world, but you wouldn’t run Linux on e.g. an MSP430, even if you somehow had a compiler that would support that.
This is why the idea for Rust in the kernel, for now, only targets drivers. Drivers are target specific, so you can use it only for drivers on architectures that are LLVM capable.
Note that the portability issue mentioned by many here is much less of an issue when writing drivers. After all drivers tend to be architecture specific.
This is why the idea is to start using Rust in the kernel for drivers.
