Microkernel Architectures
We chatted a little bit about microkernels, also known as exokernels, and their architectural advantages, as well as their practical limitations. In particular, we traced the evolution from Mach to NextOS to OS X. The following are good resources that track our discussion:We spoke about one lasting legacy from this era of research: User-space file systems.
User-space file systems
Novel in-kernel file systems can be very brittle. They rely upon system calls and other kernel resources, that can change over time. As they change, the file system needs to change to accomodate. As a result, file system and kernel development need to be synchrnoized or effort is wasted porting old versions of the file system to newer kernels and vice-versa. This becomes more painful when portability is concerned and multiple OS families are involved.In many cases the performance gain from in-kernel buffer management is worth the cost. But, in a huge number of cases, it is not. Things like GFS, which is quite a heavy hitter, were implemented above the kernel. The greater the scale of deployment, and the more that any penalties can be amortized across big data operations, the greater the argument for an easy-to-deploy and more universal user-level file system.
User-level file systems are also great during experimentation and development, when things are changing rapidly and lower-level portability and stability can amount to a lot of friction in what is intended to be an agile process.
User-space file systems can be implemented without special support. For example, they can be implemented through libaries, HTTP requests, etc. Alternatively, FUSE provides a stable, portable framework for integrating a file system into the (linux) kernel -- without ever needing to touch the kernel.
FUSE: Linux User Space File Systems
Our discussion about FUSE leaned heavily upon the following: