Only the microkernel material from these notes is examinable!
Consider the following kernel:
It is a monolith. There is not much fault isolation (kernels typically have faults in things such as device drivers) and it doesn’t look like it has much in terms of least privilege. We could try fixing this by using a microkernel architecture.
Microkernel
In the microkernel architecture, we split the kernel up into smaller pieces:
This means moving more things out of the kernel such as:
- device drivers
- file and network abstractions
- paging
to server processes, but this introduces inter-process communication overhead, and much more crossing of protection boundaries.
Link to original
Prior work on L3 and L4 microkernels (Liedtke, SOSP ‘93) showed that architecture-aware optimisations of IPC could reduce these overheads.
clueless
What has been achieved in Linux and other ‘clones’?
The architecture hasn’t changed from Unix to derivatives, still using the same monolithic kernel design with no fault isolation of device drivers and no least privilege of kernel components. We have the same old Unix user-space API: files, pipes, bytes, etc with no ‘objects’, RTC, capabilities.
It is not a research OS and prioritises performance (concurrency and scheduling) and reliability (but without kernel fault isolation).
Kernel concurrency in Linux
An OS kernel is a highly concurrent program with many threads running (possibly on many CPUs) with interrupt handling adding further asynchrony. Linux has progress from a simple ‘big lock’ (‘BKL’) to increasingly fine-grained locking and much use of lock-free design.
To avoid deadlock, we avoid code patterns that take out multiple locks. In the case of Linux, development is too decentralised to provide documented ‘global lock order’.
Even with fine-grained locking, locks may cause scalability problems specifically for read availability (reads are more common than writes). A classic write lock freezes out readers decreasing read availability. Instead we use Read, Copy, Update (RCU) which is a lock-free technique whereby:
- writers must take a copy (e.g. of a whole linked list) in order to update
- creates an illusion of atomic switchover
- it is actually atomic because of the instantaneous head pointer update
- writer then waits for all ‘stale readers’ to finish
- when write completes, it is visible to everyone
Stale reads are still possible but consistency is maintained.
Kernel interfaces / quality control
Linux is made reliable without fault isolation by aggressive quality control:
- ‘drivers should be merged into kernel tree’
- complements free software ethos / ‘develop in public’
- convenient for kernel developers, e.g. refactoring
Linux’s internal kernel interfaces are very unstable, device drivers written months ago have a low chance of working with a recent kernel. However, Linux’s system call interface is very stable and binary programs compiled decades ago will still work on a modern kernel.
Windows picks different trade-offs here.