Microkernel: Difference between revisions

The memory manager *may* be implemented in userspace - doesn't have to be.
[unchecked revision][unchecked revision]
(Merge "External Links" and "See Also" ("Recommended Reading" is still a "child" of the former one))
(The memory manager *may* be implemented in userspace - doesn't have to be.)
 
(One intermediate revision by one other user not shown)
Line 2:
== Design ==
[[Image:Microkernel.png|frame|right|Basic overview of a microkernel]]
A Microkernel tries to run most services - like networking, filesystem, etc. - as daemons / servers in user space. All that's left to do for the kernel are basic services, like physical memory allocation (however, the actual memory '''manager''' ismay be implemented in userspace), scheduling, and messaging (Inter Process Communication).
 
In theory, this concept makes the kernel more responsive (since much functionality resides in preemptible user-space threads and processes, removing the need for context-switching into the kernel proper), and improves the stability of the kernel by reducing the amount of code running in kernel space. There are also additional benefits for OS' that support multi-CPU computers (much simpler re-entrancy protection and better suitability for asynchronious functionality) and distributed OS' (code can use services without knowing if the service provider is running on the same computer or not). A drawback is the amount of messaging and Context Switching involved, which makes microkernels conceptually slower than monolithic kernels. (This isn't to say that a smartly designed microkernel could not beat a foolishly designed monolithic one.)
Line 26:
* [[Topic:10099|microkernels]]
* [[Topic:10234|discussing microkernel vs modular macrokernel]]
 
=== External Links ===
* [http://directory.google.com/Top/Computers/Software/Operating_Systems/Microkernel/ 'microkernel' google directory]
 
==== Recommended Reading ====
Anonymous user