Exokernel: Difference between revisions

1,036 bytes added ,  5 years ago
m
no edit summary
[unchecked revision][unchecked revision]
m (link updates)
mNo edit summary
 
(6 intermediate revisions by 4 users not shown)
Line 2:
 
Exokernels are an attempt to separate security from abstraction, making non-overrideable parts of the operating system do next to nothing but securely multiplex the hardware. The goal is to avoid forcing any particular abstraction upon applications, instead allowing them to use or implement whatever abstractions are best suited to their task without having to layer them on top of other abstractions which may impose limits or unnecessary overhead. This is done by moving abstractions into untrusted user-space libraries called "library operating systems" (libOSes), which are linked to applications and call the operating system on their behalf.
 
Exokernels are often compared to (or conflated with) hypervisors, and the implementations of both are usually quite similar, especially when hardware virtualization is used; most exokernels can in fact serve as a hypervisor for other OSes, if one chooses to. However, the use cases are radically different - the purpose of a hypervisor is ''providing'' an abstraction over the hardware, whereas the purpose of an exokernel is to make such an abstraction unnecessary. Furthermore, in most current uses, the hypervisor itself is running as or in an instance of a general-purpose OS. While the move to 'containerized' clients for hypervisors can be seen as a hybrid of the two ideas (at least on a conceptual level), in practice they are not the same.
 
== Exokernel Concept ==
Line 29 ⟶ 31:
It can be difficult to design exokernel interfaces. The designer must develop adequate and appropriate interfaces to low level hardware and delicately balance power and minimalism vs. enough protection. Engler et al. remark that their exokernel interfaces went through many revisions.
 
The ease of creation and mixing of libOSes could lead to code messes that would be a nightmare for maintenance coders and system administrators. MantainenceMaintenance coders would have to deal with not only the application code, but any overriden abstractions or new implementations.
 
Information that could otherwise be useful to a kernel can be lost if the related abstractions are implemented in libOSes rather than the kernel.
Line 39 ⟶ 41:
=== Nanokernel/Picokernel ===
 
Nanokernels and picokernels are usually small kernels considered by their creators to be even smaller than [[Microkernel|microkernels]]. Examples include: [http://home.gna.org/adeos/ Adeos], [http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html KeyKOS], and [http://lseos.sourceforge.net/ LSE/OS]. Another very famous example is the symbian EKA2 kernel. This nanokernel implements drivers inside the kernel making it not fully a microkernel.
 
=== Cache Kernel ===
Line 48 ⟶ 50:
 
Virtualizing kernels are usually designed to allow multiple operating systems to run on a single computer, by allowing free execution of unprivileged instructions and trapping and simulating privileged instructions. Adeos, while it calls itself a nanokernel, is similar in concept to virtualizing kernels. Unlike exokernels, virtualizing kernels attempt to be as transparent as possible, to avoid requiring many modifications, if any, to the hosted operating systems.
 
== See Also ==
 
=== Papers ===
 
[http://u.cs.biu.ac.il/~wiseman/2os/microkernels/exokernel.pdf The Exokernel Operating System Architecture]
 
[[Category:Kernel]]
Anonymous user