3 ms·
This is the recurring argument about "monolithic kernels" vs "microkernels". In the latter different user-space processes can be used to implement filesystems,
by stevekemp 9y ago
This is the recurring argument about "monolithic kernels" vs "microkernels". In the latter different user-space processes can be used to implement filesystems, networking, etc.
There are a lot of small operating systems that take the decoupled route - but you'll almost certainly never see them because they're either research-based, or suffer from the problem of most hobbyist operating systems which is "lack of hardware support". Doesn't matter how modern/sexy an O/S is if you cant run it upon your hardware. (Relatedly once you can run it you need software on it too..)
That said there are some compromises available, even with Linux. If you use something like FUSE you can write your own filesystem in 100% user-space - something I've done for a couple of niche applications.
- akavel 9y agoNotably, NetBSD has recently undergone a successful effort to implement such a decoupling of subsystems, while still remaining a monolithic kernel. Lo and behold, it immediately boosted the ecosystem of hobbyist FOSS OSes, by letting them easily reuse chosen subsystems (see e.g. Haiku, GenodeOS). It also certainly helped that NetBSD is BSD-licensed. If you want to learn more about the effort, search about "rump kernel".
- bjackman 9y agoIt's also not just about monolithic Vs microkernel: Linux could decouple filesystem drivers without becoming a unikernel e.g. by specifying a fixed driver API - you could just load FSs as kernel modules. The reason for tight coupling is just that devs don't want to commit to a stable API. If you are only talking about a single kernel version, FS drivers actually _are_ decoupled this way (can be loaded as modules) and distributors do this.