Let's Embed a Go Program into the Linux Kernel
49 points by rw-rw-rw-
49 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.
It pauses for user-perceptibly amounts of time because they don't just allow, but actively encourage in their developer documentation, third-party drivers to run arbitrary computation in interrupt handlers. That's not something that a desktop OS should do. This is less apparent on multicore systems where there's hopefully another thread making progress on another core, but on systems with only a few cores you can see the entire UI freeze during periods of high I/O.
Interesting. I have been using Windows since Windows 3.1 and I've never noticed this (the last Windows I've used was Windows 10, I've since abandoned this OS due to Microsoft's antics). The only GUI stutters I've observed were badly written programs where the GUI thread blocks or if my GPU was not able to render complex scenes in the allotted time. And after Windows 7, the compositor became slow and bloated. But I haven't used anything less than a 4C/8T CPU in a desktop in a long time.
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!
At first glance, this might sound outlandish and of little use
... and not a little scary...