Aug 29, 2017
Chapter Two -- Operating-System Structures -- Lecture Notes
- 2.0 Chapter Objectives
- Describe OS Services
- Discuss Design of OS Structure
- Explain Installation, Customization, and Booting
- 2.1 Operating-System Services
- Services typically provided by an operating system include:
- user interfaces,
- program execution,
- control of I/O devices,
- file-system manipulation,
- process communication facilities,
- error detection,
- resource allocation services,
- accounting (for billing or usage research),
- protection, and
- 2.2 User and Operating-System Interface
- An OS must provide users with an interface for making requests for
system services - i.e. command interpreter, shell, or GUI.
- The user-interface process may perform requested operations
directly or may start up a child process to run a separate program
which performs the service. The second approach is more modular.
- The user-interface is not considered fundamental to the study of
operating systems. We study mostly what exists from the system call
level and down to the interface with the hardware.
- To the authors of our text, a user-interface program or other system
program that functions above the system-call level is just another
user program, and NOT part of the operating system.
- 2.3 System Calls
- A system call is like a function call. It is a request for an OS
- Typically the OS is in charge of controlling I/O, so an application
that wants to copy or move data in either direction between the RAM
and a peripheral device must call upon the OS by making a system
- Typically a computer executes thousands of system calls per second.
- The run-time support functions in libraries provide the system-call
interface for many programming languages - including C and Java.
- Typically, there is a number associated with each system call. When
the trap caused by the system call puts the OS into the CPU, the OS
looks up the system call in a table maintained by the OS,
using the system call number to index the appropriate entry of the table.
The table entry tells the OS which code routine to run. The OS executes
that code routine, and the routine performs the service required
by the system call.
- VERY IMPORTANT DETAIL: A process can pass parameters to a system
call by leaving them in CPU registers, by leaving them in a RAM
block (pointed to by an address in a register), or by pushing them
onto the runtime stack.
- 2.4 Types of System Calls
- There are system calls for:
- process control,
- file manipulation,
- device manipulation,
- information maintenance
- communication, and
- Process control:
- end, abort
- load, execute
- create & terminate process,
- get or set process attributes,
- wait for a specific amount of time,
- wait for or signal an event,
- acquire or release lock on data,
- allocate and free memory.
In the MS-DOS style of process control, processes run 'one at a
time' - there is no multiprogramming. In fact, the command
interpreter part of the OS overwrites much of itself when it
loads a user process to execute. The remaining part of the
command processor reloads the rest of the command processor
after the user process exits.
Flavors of unix like Free BSD employ a user shell capable of
spawning (via fork and exec system calls) a child
process that may excecute concurrently with the parent shell. There
is no overwriting of the OS associated with loading a user process,
as is the case with MS-DOS. Many processes typically execute
- File Management:
- create and delete file,
- open and close file,
- read and write file,
- move and copy file,
- reposition file,
- get & set file attributes (e.g. name, type, protection codes,
- Device Management:
- request device (important for dealing with contention & deadlock),
- release device (important for dealing with contention & deadlock),
- read from and write to device,
- reposition device,
- get & set device attributes,
- logically attach or detach device.
The term device may refer to real physical devices such as
hard drives, or abstract (virtual) devices such as files.
- Information Maintenance:
- get or set time or date,
- get system data (e.g. number of current processes or
amount of free memory),
- dump memory,
- get or set process, file, or device attributes,
- process tracing and profiling capabilities.
- get host or process identifier,
- create/open or delete/close communications connection,
- accept communications connection,
- wait for request for communications connection,
- write/send or read/receive message,
- transfer status information,
- attach or detach remote devices,
- shared memory create or attach
The style of communication may be via message passing or via shared
memory. Message passing is easy to implement but may be slow. When
available, communication via shared memory is fast but requires
sophisticated protection and synchronization schemes.
- get and set permissions, and
- allow and deny user.
- 2.5 System Programs
- Typically there are system programs that organize access to system
calls for the convenience of users. There may be system programs
- file management,
- status information,
- file modification,
- programming-language support,
- program loading and execution,
- communications and/or
- background services (daemons).
- Most computer users seldom, if ever, directly use system calls. They rely
on system calls indirectly, through the use of APIs, system programs,
and higher-level applications
- 2.6 Operating-System Design and Implementation
- An OS is software and design of the OS is a problem in software
engineering. The principles of good software design certainly apply
to OS development.
- Designers should try to be guided by the anticipated needs of the
intended users of the system.
- Separation of Policy from Mechanism is a design
principle important for flexibility. It allows the system
to be configured in different ways according to policy, for
example a mechanism that supports different CPU scheduling
- Typically a few parts of an OS have to be written in assembly
- However modern operating systems are written almost entirely in a
high-level programming language such as C. Actually several
different high level languages may be used to implement
various parts of an operating system. Advantages: code is
developed faster; is smaller, easier to understand, debug and
change; and easier to port.
- There are some things that just can't be done with high-level
language statements, for example some device-driver code and
instructions that save and restore register values.
- There was a time when writing more of the code in assembly could be
justified because assembly programmers could use 'tricks' that made
routines run faster by some constant factor compared with compiled
high level code. Modern optimizing compilers have eliminated that
advantage almost entirely, although there are still a few
bottlenecks in systems that are 'hand-coded' in assembly language in
order to achieve 'the absolute maximum' efficiency - e.g. the
authors mention memory managers and CPU schedulers in this regard.
- As the authors say: "As is true in other systems, major performance
improvements in operating systems are more likely to be the result
of better data structures and algorithms than of excellent
- 2.7 Operating-System Structure
- As with any software project, an OS should be designed with
appropriate attention to information hiding and modularity.
- However, well-known operating systems such as MS-DOS and the
original unix had monolithic designs -- i.e. they were NOT modular.
- One way to achieve the goals of information hiding and modularity is
to create a layered design, in which each layer depends only on the
functionality of layers beneath it. A layered system may be built
from the bottom up. If there are problems, one can always be certain
that they are in the layer currently under construction. The main
disadvantages of this approach are first the difficulty of
conceiving of layers without any circular dependencies, and second
the fact that each layer adds overhead which slows down the
operation of the system.
- There is a microkernel approach to OS design. The idea is to remove
all functions possible from the kernel and implement them as system
and user-level applications. For example, file systems can be
implemented at the user level.
- Typically the remaining microkernel provides some process control,
memory management, and process communication facilities.
- Microkernel systems tend to be bug-free, secure, easy to modify and
easy to port.
- The main disadvantage seems to be the overhead created by the need
for user-level parts of the system to communicate through the
kernel (e.g. message-passing with kernel serving as go-between).
- The design style that is currently popular is similar to the
microkernel except that it employs dynamically loadable user-level
modules which are not constrained to communicate through the kernel.
- Actual operating systems are usually structured as some sort of hybrid
of the structures described above. For example, Windows is largely
monolithic, but supports user-mode subsystems and dynamically loadable
- 2.8 Operating-System Debugging
- When an OS crashes typically the contents of kernel memory are saved
in a special file or disk partition. By studying these 'core
(memory) dumps' and log files, system designers can glean
information useful for debugging OS code.
- It is very important to study existing systems in order to learn how
to build better systems. For example, this was one of the 'secrets
of success' of the developers of Berkeley Unix. It is important to
build system-monitoring code into the OS. Such systems produce
"traces" of their operation - they write records of all
'interesting' system events in log files which can be analyzed
- There are also online monitoring tools - applications that are able
to display performance characteristics of a running system - such as
the percentage of CPU time used by each process, average length of
I/O queues, current amount of free primary memory, and so forth.
- 2.9 Operating-System Generation
- Systems have to be configured for the specific site to which they
are targeted. For example, we perform system generation when we
put a new host online, providing at that time, for example, a
hostname, host IP address, router IP address.
- Other SYSGEN operations possible: disk partitioning, installation of
device drivers, choice of CPU-scheduling algorithm, and setting of
the maximum number of processes to be supported.
- The SYSGEN information may be incorporated into the source code for
the OS, and a custom version of the OS then compiled.
- Another option is for the system to be pre-compiled and the SYSGEN
information saved in the form of tabular information in files,
accessed and utilized by the pre-compiled OS in order to achieve the
desired customization effects. For example the system can read its
hostname and default router from a configuration file. Scripts
written during the SYSGEN can be executed each time the computer
boots in order to perform custom setups.
- Tables can determine which of certain dynamically loadable modules
are to be loaded at boot time.
- SYSGEN may be followed by a linking, but not compiling step, so that
certain modules such as drivers are incorporated into a permanent
executable image of the kernel.
- 2.10 System Boot
- Modern computers have ROM that begins executing automatically at
system start-up time.
- The ROM boot program will typically run diagnostics,
initialize the hardware, and load the OS from disk
(or it might load a secondary boot program from disk,
which in turn loads the OS from disk, or there might be both
secondary and tertiary boot programs on disk).
- In some small devices, the entire OS may be in ROM or EPROM.