Kernel: Difference between revisions
From COMP15212 Wiki
 Yuron [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)m (1 revision imported) |
 W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{#set: Priority=3 | Summary=The central, essential part of an operating system. Approaches vary.}}<!-- | {{#set: Priority=3 | Summary=The central, essential part of an operating system. Approaches vary.}}<!-- | ||
-->{{#invoke:Dependencies|add|What is an OS,4}} | -->{{#invoke:Dependencies|add|What is an OS,4}} | ||
The <strong>kernel</strong> is the <strong>core</strong> of an operating system; the part which | The <strong>kernel</strong> is the <strong>core</strong> of an operating system; the part which resides in [[Memory_Protection|protected space]], including the [[Processes|process manager]], [[Scheduler|<strong>scheduler</strong>]], | ||
resides in [[Memory_Protection|protected space]], including the | [[Interprocess_Communication|interprocess communication]], [[Exceptions|exception handlers]], [[Resources|resource managers]] etc. It is isolated from the user space (assuming the processor/system architecture allows this – most ‘large’ systems do, these days) and connected by [[System_Calls|system calls]]. | ||
[[Processes|process manager]], [[Scheduler|<strong>scheduler</strong>]], | |||
[[Interprocess_Communication|interprocess communication]], [[Exceptions|exception | |||
handlers]], [[Resources|resource managers]] etc. It is | |||
isolated from the user space (assuming the processor/system | |||
architecture allows this – most ‘large’ systems do, these | |||
days) and connected by [[System_Calls|system calls]]. | |||
<span style="color:green">Is the “kernel” the <em>same</em> as the | <span style="color:green">Is the “kernel” the <em>same</em> as the “operating system”?</span> | ||
“operating system”?</span> | |||
<blockquote> | <blockquote> | ||
<strong>Maybe</strong>: it depends on your design philosophy. | <strong>Maybe</strong>: it depends on your design philosophy. | ||
</blockquote> | </blockquote> | ||
The kernel is responsible for implementing <em>mechanisms</em>; the debate | The kernel is responsible for implementing <em>mechanisms</em>; the debate is whether it should also be responsible for <em>policy</em>. Time for an example: | ||
is whether it should also be responsible for <em>policy</em>. Time for an | |||
example: | |||
*A scheduling <strong>mechanism</strong> includes the code which saves the [[context]] of one process and restores the context of another. It may be highly specific to a particular processor [[Extra:ISA|ISA]]. | *A scheduling <strong>mechanism</strong> includes the code which saves the [[context]] of one process and restores the context of another. It may be highly specific to a particular processor [[Extra:ISA|ISA]]. | ||
*A scheduling <strong>policy</strong> is responsible for <em>when</em> to switch: decisions on time-slicing, priority etc. This is generally fairly processor-agnostic. | *A scheduling <strong>policy</strong> is responsible for <em>when</em> to switch: decisions on time-slicing, priority etc. This is generally fairly processor-agnostic. | ||
Similar examples can be constructed for memory management, filing | Similar examples can be constructed for memory management, filing systems etc. | ||
systems etc. | |||
== Types of Kernel == | == Types of Kernel == | ||
| Line 43: | Line 33: | ||
=== [https://en.wikipedia.org/wiki/Microkernel Microkernel] === | === [https://en.wikipedia.org/wiki/Microkernel Microkernel] === | ||
<span style="color:green"><strong>No</strong>.</span> | <span style="color:green"><strong>No</strong>.</span> | ||
The kernel contains the handlers which <em>need</em> to be privileged but functions which do not – examples might include the [[Filing_System|filing system]], graphical user interface (GUI) and [[Device_Drivers|device drivers]] – are | The kernel contains the handlers which <em>need</em> to be privileged but functions which do not – examples might include the [[Filing_System|filing system]], graphical user interface (GUI) and [[Device_Drivers|device drivers]] – are separated as <em>user-mode processes</em>. This keeps the size of the ‘sensitive’ code down, which is likely to improve reliability as it’s easier to modify and maintain. Only the <em>required</em> device drivers need to be loaded and a fault in one of these (a likely source of problems) cannot crash the kernel itself. | ||
separated as <em>user-mode processes</em>. This keeps the size of the | |||
‘sensitive’ code down, which is likely to improve | |||
reliability as it’s easier to modify and maintain. Only the | |||
<em>required</em> device drivers need to be loaded and a fault in one of | |||
these (a likely source of problems) cannot crash the kernel itself. | |||
[[Image:microkernel.png|link=|alt=Microkernel]] | [[Image:microkernel.png|link=|alt=Microkernel]] | ||
| Line 62: | Line 47: | ||
<span style="color:green"><strong>Not entirely</strong>.</span> | <span style="color:green"><strong>Not entirely</strong>.</span> | ||
A hybrid kernel is a compromise: | A hybrid kernel is a compromise: | ||
a microkernel with some functions inside the ‘privilege’ | a microkernel with some functions inside the ‘privilege’ boundary for efficiency. | ||
boundary for efficiency. | |||
<blockquote> | <blockquote> | ||
Some other approaches – and lots of detail – can be found with a | Some other approaches – and lots of detail – can be found with a little research: [https://en.wikipedia.org/wiki/Kernel_%28operating_system%29 here’s a start]. | ||
little research: [https://en.wikipedia.org/wiki/Kernel_%28operating_system%29 here’s a start]. | |||
</blockquote> | </blockquote> | ||
| Line 74: | Line 57: | ||
[https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate Not everyone agrees!] | [https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate Not everyone agrees!] | ||
---- | ---- | ||
{{BookChapter|1.1.3|5-7}} | |||
{{PageGraph}} | {{PageGraph}} | ||
Latest revision as of 10:03, 5 August 2019
| Depends on | What is an OS |
|---|
The kernel is the core of an operating system; the part which resides in protected space, including the process manager, scheduler, interprocess communication, exception handlers, resource managers etc. It is isolated from the user space (assuming the processor/system architecture allows this – most ‘large’ systems do, these days) and connected by system calls.
Is the “kernel” the same as the “operating system”?
Maybe: it depends on your design philosophy.
The kernel is responsible for implementing mechanisms; the debate is whether it should also be responsible for policy. Time for an example:
- A scheduling mechanism includes the code which saves the context of one process and restores the context of another. It may be highly specific to a particular processor ISA.
- A scheduling policy is responsible for when to switch: decisions on time-slicing, priority etc. This is generally fairly processor-agnostic.
Similar examples can be constructed for memory management, filing systems etc.
Types of Kernel
Monolithic Kernel
Yes. Everything is included in the kernel and runs in the privileged mode. All the routines have direct access to the operating system’s memory.
Disadvantages:
- Size: code continues to ‘bloat’ as it develops which makes management difficult.
- Reliability: an introduced bug in one place can crash the whole system.
- Portability: it is harder to adapt a large slab of code for a new system/architecture.
Microkernel
No. The kernel contains the handlers which need to be privileged but functions which do not – examples might include the filing system, graphical user interface (GUI) and device drivers – are separated as user-mode processes. This keeps the size of the ‘sensitive’ code down, which is likely to improve reliability as it’s easier to modify and maintain. Only the required device drivers need to be loaded and a fault in one of these (a likely source of problems) cannot crash the kernel itself.
Disadvantages:
- Speed: the additional needs for communications (and extra system calls) leads to a greater overhead from the O.S.
- Complexity: greater complexity gives more potential for problems.
Hybrid Kernel
Not entirely. A hybrid kernel is a compromise: a microkernel with some functions inside the ‘privilege’ boundary for efficiency.
Some other approaches – and lots of detail – can be found with a little research: here’s a start.
Which is best?
That depends who you ask. And what it’s for.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 1.1.3, pages 5-7 |
|---|
