A monolithic kernel is a kernel where all services (file system, VFS, device drivers, etc) as well as core functionality (scheduling, memory allocation, etc) are a tight knit group sharing the same space. This directly opposes a micro kernel.
A micro kernel prefers an approach where core functionality is isolated from system services and device drivers (which are basically just system services).
For instance, VFS (virtual file system) and block device file systems (i.e. ext3) are separate processes that run outside of the kernel's space, using IPC to communicate with the kernel, other services and user processes. In short, if its a module in Linux, its a service in a micro kernel, indicating an isolated process.
Do not confuse the term modular kernel to be anything but monolithic. Some monolithic kernels can be compiled to be modular (e.g Linux), what matters is that the module is inserted to and run from the same space that handles core functionality.
The advantage to a micro kernel is that any failed service can be easily re-started, for instance .. no kernel halt if the root file system throws an abort.
The disadvantage to a micro kernel is that asynchronous IPC messaging can become very difficult to debug. Additionally, just tracking down a FS/write issue means examining the user space process, the block device service, VFS service, file system service and (possibly) the PCI service. If you get a blank on that, its time to look at the IPC service. This is often easier in a monolithic kernel. GNU Hurd[1] suffers from these debugging problems. I'm not even going to go into checkpointing when dealing with complex message queues. Micro kernels are not for the faint of heart.
The shortest path to a working, stable kernel is the monolithic approach. Either approach can offer a POSIX[2] interface, where the design of the kernel becomes of little interest to someone simply wanting to write code to run on any given design.
[1] http://www.gnu.org/software/hurd/hurd.html
[2] http://en.wikipedia.org/wiki/POSIX
A micro kernel prefers an approach where core functionality is isolated from system services and device drivers (which are basically just system services).
For instance, VFS (virtual file system) and block device file systems (i.e. ext3) are separate processes that run outside of the kernel's space, using IPC to communicate with the kernel, other services and user processes. In short, if its a module in Linux, its a service in a micro kernel, indicating an isolated process.
Do not confuse the term modular kernel to be anything but monolithic. Some monolithic kernels can be compiled to be modular (e.g Linux), what matters is that the module is inserted to and run from the same space that handles core functionality.
The advantage to a micro kernel is that any failed service can be easily re-started, for instance .. no kernel halt if the root file system throws an abort.
The disadvantage to a micro kernel is that asynchronous IPC messaging can become very difficult to debug. Additionally, just tracking down a FS/write issue means examining the user space process, the block device service, VFS service, file system service and (possibly) the PCI service. If you get a blank on that, its time to look at the IPC service. This is often easier in a monolithic kernel. GNU Hurd[1] suffers from these debugging problems. I'm not even going to go into checkpointing when dealing with complex message queues. Micro kernels are not for the faint of heart.
The shortest path to a working, stable kernel is the monolithic approach. Either approach can offer a POSIX[2] interface, where the design of the kernel becomes of little interest to someone simply wanting to write code to run on any given design.
[1] http://www.gnu.org/software/hurd/hurd.html
[2] http://en.wikipedia.org/wiki/POSIX
Последна модификация: Monday, 7 January 2013, 03:34 PM