Exokernels are actually pretty different from microkernels (although the difference is somewhat orthogonal, rather than mutually exclusive).
Microkernels implement things like drivers and file systems in servers, essentially taking a piece of a monolithic kernel and moving it into a process. Applications still need to go through this interface to get things done without violating protection, so applications still can’t e.g. change around file system disk block allocation algorithms, or make their own decisions regarding swapping.
Exokernels, on the other hand, provide protection at a lower level- applications can access things like disk blocks directly rather than through a privileged server. This is typically done through libraries which run with exactly the same privileges as the application itself, but which can be bypassed for greater flexibility. For example, database indexes are sometimes faster to regenerate than to swap in from disk, so a database application could choose to discard indices rather than having its LRU page swapped out.
This is why exokernel research tends to show performance improvements over monolithic kernels, and microkernels research tends to be about minimizing performance losses compared to monolithic kernels. 😛
As I mentioned, you could easily have a microkernel whose servers expose their interfaces at the exokernel level rather than at the monolithic level. This would work really well on the Mill, where separating what would ordinarily be pieces of a kernel into services has a much lower cost.
-
This reply was modified 10 years, 3 months ago by
Russell Johnston.