|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 1038-1039 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 1038
SEC. 12.3
IMPLEMENTATION
1007
#include "config.h"
#include "config.h"
init( )
#if (WORD
LENGTH == 32)
{
typedef int Register;
#if (CPU == IA32)
#endif
/
*
IA32 initialization here.
*
/
#endif
#if (WORD
LENGTH == 64)
typedef long Register;
#if (CPU == ULTRASPARC)
#endif
/
*
UltraSPARC initialization here.
*
/
#endif
Register R0, R1, R2, R3;
(a)
(b)
}
Figure 12-6.
(a) CPU-dependent conditional compilation. (b) Word-length-de-
pendent conditional compilation.
To compile the system for the UltraSPARC, a different
config.h
would be used,
with the correct values for the UltraSPARC, probably something like
#define CPU ULTRASPARC
#define WORD
LENGTH 64
Some readers may be wondering why
CPU
and
WORD
LENGTH
are handled
by different macros.
We could easily have bracketed the definition of
Register
with a test on
CPU
, setting it to 32 bits for the IA32 and 64 bits for the Ultra-
SPARC. However, this is not a good idea. Consider what happens when we later
port the system to the 32-bit ARM.
We would have to add a third conditional to
Fig. 12-6(b) for the ARM.
By doing it as we have, all we have to do is include the
line
#define WORD
LENGTH 32
to the
config.h
file for the ARM.
This example illustrates the orthogonality principle we discussed earlier. Those
items that are CPU dependent should be conditionally compiled based on the
CPU
macro, and those that are word-length dependent should use the
WORD
LENGTH
macro. Similar considerations hold for many other parameters.
Indirection
It is sometimes said that there is no problem in computer science that cannot
be solved with another level of indirection. While something of an exaggeration,
there is definitely a grain of truth here.
Let us consider some examples. On
x86-based systems, when a key is depressed, the hardware generates an interrupt
and puts the key number, rather than an ASCII character code, in a device register.
Page 1039
1008
OPERATING SYSTEM DESIGN
CHAP. 12
Furthermore, when the key is released later, a second interrupt is generated, also
with the key number. This indirection allows the operating system the possibility of
using the key number to index into a table to get the ASCII character, which makes
it easy to handle the many keyboards used around the world in different countries.
Getting both the depress and release information makes it possible to use any key
as a shift key, since the operating system knows the exact sequence in which the
keys were depressed and released.
Indirection is also used on output. Programs can write ASCII characters to the
screen, but these are interpreted as indices into a table for the current output font.
The table entry contains the bitmap for the character.
This indirection makes it
possible to separate characters from fonts.
Another example of indirection is the use of major device numbers in UNIX.
Within the kernel there is a table indexed by major device number for the block de-
vices and another one for the character devices. When a process opens a special
file such as
/dev/hd0
, the system extracts the type (block or character) and major
and minor device numbers from the i-node and indexes into the appropriate driver
table to find the driver. This indirection makes it easy to reconfigure the system,
because programs deal with symbolic device names, not actual driver names.
Yet another example of indirection occurs in message-passing systems that
name a mailbox rather than a process as the message destination.
By indirecting
through mailboxes (as opposed to naming a process as the destination), consid-
erable flexibility can be achieved (e.g., having a secretary handle her boss’ mes-
sages).
In a sense, the use of macros, such as
#define PROC
TABLE
SIZE 256
is also a form of indirection, since the programmer can write code without having
to know how big the table really is.
It is good practice to give symbolic names to
all constants (except sometimes
−
1, 0, and 1), and put these in headers with com-
ments explaining what they are for.
Reusability
It is frequently possible to reuse the same code in slightly different contexts.
Doing so is a good idea as it reduces the size of the binary and means that the code
has to be debugged only once. For example, suppose that bitmaps are used to keep
track of free blocks on the disk. Disk-block management can be handled by having
procedures
alloc
and
free
that manage the bitmaps.
As a bare minimum, these procedures should work for any disk. But we can go
further than that.
The same procedures can also work for managing memory
blocks, blocks in the file system’s block cache, and i-nodes.
In fact, they can be
used to allocate and deallocate any resources that can be numbered linearly.
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
