|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 95-96 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 95
64
INTRODUCTION
CHAP. 1
Main
procedure
Service
procedures
Utility
procedures
Figure 1-24.
A simple structuring model for a monolithic system.
1.7.2 Layered Systems
A generalization of the approach of Fig. 1-24 is to organize the operating sys-
tem as a hierarchy of layers, each one constructed upon the one below it. The first
system constructed in this way was the THE system built at the Technische Hoge-
school Eindhoven in the Netherlands by E. W. Dijkstra (1968) and his students.
The THE system was a simple batch system for a Dutch computer, the Electrolog-
ica X8, which had 32K of 27-bit words (bits were expensive back then).
The system had six layers, as shown in Fig. 1-25. Layer 0 dealt with allocation
of the processor, switching between processes when interrupts occurred or timers
expired. Above layer 0, the system consisted of sequential processes, each of
which could be programmed without having to worry about the fact that multiple
processes were running on a single processor.
In other words, layer 0 provided the
basic multiprogramming of the CPU.
Layer
Function
5
The operator
4
User programs
3
Input/output management
2
Operator-process communication
1
Memory and drum management
0
Processor allocation and multiprogramming
Figure 1-25.
Structure of the THE operating system.
Layer 1 did the memory management.
It allocated space for processes in main
memory and on a 512K word drum used for holding parts of processes (pages) for
which there was no room in main memory. Above layer 1, processes did not have
to worry about whether they were in memory or on the drum; the layer 1 software
Page 96
SEC. 1.7
OPERATING SYSTEM STRUCTURE
65
took care of making sure pages were brought into memory at the moment they
were needed and removed when they were not needed.
Layer 2 handled communication between each process and the operator con-
sole (that is, the user). On top of this layer each process effectively had its own op-
erator console.
Layer 3 took care of managing the I/O devices and buffering the
information streams to and from them. Above layer 3 each process could deal with
abstract I/O devices with nice properties, instead of real devices with many pecu-
liarities. Layer 4 was where the user programs were found.
They did not have to
worry about process, memory, console, or I/O management. The system operator
process was located in layer 5.
A further generalization of the layering concept was present in the MULTICS
system. Instead of layers, MULTICS was described as having a series of concentric
rings, with the inner ones being more privileged than the outer ones (which is ef-
fectively the same thing).
When a procedure in an outer ring wanted to call a pro-
cedure in an inner ring, it had to make the equivalent of a system call, that is, a
TRAP
instruction whose parameters were carefully checked for validity before the
call was allowed to proceed. Although the entire operating system was part of the
address space of each user process in MULTICS, the hardware made it possible to
designate individual procedures (memory segments, actually) as protected against
reading, writing, or executing.
Whereas the THE layering scheme was really only a design aid, because all the
parts of the system were ultimately linked together into a single executable pro-
gram, in MULTICS, the ring mechanism was very much present at run time and
enforced by the hardware. The advantage of the ring mechanism is that it can easi-
ly be extended to structure user subsystems. For example, a professor could write a
program to test and grade student programs and run this program in ring
n
, with
the student programs running in ring
n
+
1 so that they could not change their
grades.
1.7.3 Microkernels
With the layered approach, the designers have a choice where to draw the ker-
nel-user boundary. Traditionally, all the layers went in the kernel, but that is not
necessary.
In fact, a strong case can be made for putting as little as possible in ker-
nel mode because bugs in the kernel can bring down the system instantly.
In con-
trast, user processes can be set up to have less power so that a bug there may not be
fatal.
Various researchers have repeatedly studied the number of bugs per 1000 lines
of code (e.g., Basilli and Perricone, 1984; and Ostrand and Weyuker, 2002). Bug
density depends on module size, module age, and more, but a ballpark figure for
serious industrial systems is between two and ten bugs per thousand lines of code.
This means that a monolithic operating system of five million lines of code is like-
ly to contain between 10,000 and 50,000 kernel bugs. Not all of these are fatal, of
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
