Linux kernel needs more modularity for bare-metal hypervisor viability

I wrote previously about how Linux is notionally a bare-metal hypervisor.

But let me point out a sticking point w.r.t. the Linux kernel being considered a viable bare-metal hypervisor: it's HUGE! Imho, a lot of the debate over hypervisor design types, bare-metal, etc. is largely academic. When you consider the overall footprint size of the management layers, storage, authentication, domain0 stack in Xen-style hypervisors, special guest drivers, etc., the hypervisor footprint is put in a better perspective. However, it is true that modularity and smaller more manageable components are generally better designed and more auditable for errors and security issues.

When the Linux kernel was initially designed, it was a monolithic chunk of code (i.e. drivers could not be modules). Some years later, after various debate, loadable kernel module support was added. That was a big step in the right direction for code quality and modularity -- few people could imagine Linux without it today. Thereafter was one of the more storied debates on adding a pluggable scheduler -- one size does not fit all workloads. The net result is that it's now in recent Linux kernels, and again the consensus is that this was a very good thing.

So what's become of the size of the Linux kernel after such developments? Well, not that long ago I compiled an extremely stripped down recent Linux kernel for a VM. Uncompressed, the size of the kernel binary still rhymes with megabyte. That tells me there's a lot of extra baggage which needs to be modularized out. Whether it's perception, marketing, or reality, I think we need to get a slim kernel-proper down to a few hundred kilobytes or less before people consider it a bare-metal hypervisor.

Beyond consideration as a hypervisor, taking time to modularize and clean house is always a good thing, and like past modularization efforts always produces a better design and encourages more innovation. Smaller modular chunks mean people or groups of people can comprehend, analyze, audit, innovate and improve within a more manageable domain. This would go a long way towards allowing academic projects which need to be completed in one semester (nod to Andrew Tanenbaum). And with Linux development picking up steam, I think this is well needed in any case. With that, I offer the following project ideas. Sometimes people are looking for ways to help.
  1. Modularization Guru: oversee modularization of anything that can possibly be modularized, and drive changes into the mainline kernel. This gig is not for the faint of heart -- you'll need a flame-proof shield.
  2. Bloat Tracker: do minimal compiles over a history of Linux kernels and plot the size of the kernel proper with everything modularized. Keep track of new code introductions which add bloat creep. The job is to shame people to help the modularization guru.
And I'd note to the Linux crowd, that the hypervisor is becoming the new OS. Either Linux adapts, or becomes subjugated...

Disclosure: no positions