Let's Embed a Go Program into the Linux Kernel
44 points by rw-rw-rw-
44 points by rw-rw-rw-
Aside: C23’s #embed in GCC 15 should make this a little easier (and faster). No more futzing with assembly or xxding or whatever.
For a brief moment, I thought that after Rust in the Linux Kernel was no longer experimental, they would start supporting Go next. That would have been very entertaining.
That would be a great April fool’s joke. I’m sure the C-purists will take it well. 🙃
Haha you're giving me ideas... "In the kernel mailing list, Linus Torvalds begrudgingly admitted that the opposition to Rust had not abated but instead grown and that it was no longer tenable. To resolve the tension among the Linux kernel developers, which seemed like it could escalate at any given time, he made the decision to meet those who demand a safer language in the Linux kernel halfway, opting for the less strict and easier to learn programming language Go."
Sun Research added Java support to the Solaris kernel so you could write type-safe device drivers (including GC). It's easier than you'd think on a properly designed kernel that doesn't do anything in interrupt handlers except mark threads as runnable (i.e. pretty much everything that isn't Windows, which is the main reason Windows isn't ready for the desktop: it can't achieve the levels of latency required for interactive use).
ZFS includes Lua and before that NetBSD had a Lua embedding that could be used for some kernel operations.
So there's a reasonable amount of prior art for GC'd languages in a UNIX-like (and even UNIX™) kernel. Contrary to popular belief, there isn't a huge amount of code in a kernel that can't run in a GC'd world. The very low-level bits of memory management (including pinning direct-mapped regions for DMA or IPC optimisation) and so on are exceptions, but there's a lot in a kernel that isn't even particularly performance sensitive and moving this to Lua makes it easier to modify. This is also more or less the motivation for eBPF in Linux.
(i.e. pretty much everything that isn't Windows, which is the main reason Windows isn't ready for the desktop: it can't achieve the levels of latency required for interactive use).
That's a bit of a stretch, considering Windows has been the most widespread desktop operating system for decades and has pioneered many of the concepts we take for granted on a desktop computer.
Windows can be very snappy and you can do some realtime-ish workloads on some specific Windows versions, but obviously it'll never reach the real-time properties of QNX and the likes.
Loved this. No matter how open-minded I am, I still seem to reflexively think of certain tech as dark arts until I have time to explore them. Even as I have written assembly, bare metal code, etc. This was a lovely, readable exploration into just how simple the kernel is to get going and support, and I learned a lot.
Ahhh, good old call_usermodehelper, every kernel-mode Linux rootkit developer’s best friend!