Hacker News Reader

Comment by atombender | Hacker News Reader

I’ve always found it weird that things like file systems in the Linux kernel are so tightly coupled. Why isn’t, say, Ext4 written like a library? (Or is it? I don’t think it is?)

Stub out the interface that the kernel needs, and provide an interface for the bits (reading disk blocks and so on) that the file system needs from the kernel. This way, you can decouple it completely from the kernel, test it independently, port it without forking the code, and then it can easily be used in userland, too.

View on HN

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.

Notably, 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".

It'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.

This is fine until optimisations are needed. Most meaningful performance work requires changing data structures which impacts the shape of the interface.

One reason is that it helps keep Linux free by making it harder to pull code out of the tree or maintain out-of-tree drivers, which encourages people to contribute their changes upstream.

Doesn't the GPL ensure this?

You can write kernel drivers that are not GPL, which is difficult with the continuously changing internal kernel API.

Decoupling is not the strongest suit for Linux developers however as somebody pointed out there is already other projects to enable user land FS.

I feel this statement is a bit unfair. Much of the tight coupling has been a design decission. There has been a lot of public discussion about it.

This already done. FUSE

Reply on news.ycombinator.com