Kernel modules with Kotlin Native (Experiment)
This started as a joke: can a Kotlin/Native binary speak the Linux module ABI without dragging a runtime that the kernel will reject?
The short answer is “barely, and only if you throw most of Kotlin away”. The interesting part is which pieces you have to throw.
The constraints
A loadable module is not a userspace process. There is no libc, no thread that owns a GC, and no permission to page in a large runtime during init_module. That immediately rules out the stock Kotlin/Native memory manager.
What remains is a C-compatible subset:
staticdata for stateexternfunctions with theinit_module/cleanup_modulesignatures- No exceptions across the kernel boundary
What actually loaded
A stub that printed a line through printk and exported one ioctl table. The Kotlin source compiled to LLVM IR, then to an object file that ld could treat like any other *.ko input.
The moment we touched heap allocation, the module failed to load. That was the experiment: the language is usable as a typed C, not as Kotlin.
Why bother
Not to ship Kotlin in prod kernels. To see how much of a “high-level” compiler still works when the target is a hostile ABI. The same questions show up when you embed Rust in firmware or write eBPF in anything but C.