MACHAKOS UNIVERSITY
SCHOOL OF ENGINEERING & TECHNOLOGY
DEPARTMENT OF COMPUTING & INFORMATION TECHNOLOGY
Course Programme:
BSc Computer Science and Mathematics
Course Unit:
SIT 121 Introduction to Operating Systems
Semester & Academic Year
First Year Second Semester 2020/2021
Lecturer:
Mr. Raphael Kaibiru
Copyright © Machakos University, 2020
All Rights Reserved
MONTH, YEAR
MARCH, 2021
LECTURE 2: OPERATING SYSTEM STRUCTURE
1.1. Introduction
An operating system provides the environment within which programs are
executed. We can view an operating system from several vantage points. One view focuses on
the services that the system provides; another, on the interface that it makes available to users
and programmers; a third, on its components and their interconnections.
This lecture covers
1. Services of operating system
2. User and system interfaces
3. System calls and types of system calls
4. System programs
5. Operating system design and implementation
6. Operating system structure
7. Operating system debugging
8. Operating system generation
9. Operating system booting
10. Summary
11. Self-test questions
12. Reference
1.2. Lecture Objectives
At the end of this lecture the student should be able;
1. To describe the services of the operating system to the user, processes and other systems
2. To discuss various methods of structuring an operating system
3. To discuss how operating systems are installed and booted.
1.3. Services of Operating System
An operating system provides an environment for the execution of programs.
It provides certain services to programs and to the users of those programs. The specific
services provided, of course, differ from one operating system to another, but we can identify
common classes. These operating system services are provided for the convenience of the
programmer, to make the programming task easier. There are services that are meant for users
and other for the system. Figure 1 shows the services provided by the operating system.
Figure 1: Operating System Services
Services that provide functional requirements to the users include;
1.3.1. User Interface
User Interface
User interface. Almost all operating systems have a user interface (UI). This interface can
take several forms. One is a command-line interface (CLI), which uses text commands and
a method for entering them (say, a keyboard for typing in commands in a specific format
with specific options). Another is a batch interface, in which commands and directives to
1.3.2. Program Execution
Program Execution
The system must be able to load a program into memory and to run that program. The
program must be able to end its execution, either normally or abnormally (indicating error).
1.3.3. I/O Operations
I/O Operations
A running programFile System
may Manipulation
require I/O, which may involve a file or an I/O device. For specific
devices, special functions may be desired (such as recording to a CD or DVD drive or
The file system is of particular interest. Obviously, programs need to read and write files and
blanking a display screen). For efficiency and protection, users usually cannot control I/O
directories. They also need to create and delete them by name, search for a given file, and
devices directly. Therefore, the operating system must provide a means to do I/O.
list file information. Finally, some operating systems include permissions management to
allow or deny access to files or directories based on file ownership. Many operating systems
provide a variety of file systems, sometimes to allow personal choice and sometimes to
provide specific features or performance characteristics.
1.3.4. File system Manipulation
1.3.5. Communication
Communication
There are many circumstances in which one process needs to exchange information with
another process. Such communication may occur between processes that are executing on the
same computer or between processes that are executing on different computer systems tied
together by a computer network. Communications may be implemented via shared memory,
in which two or more processes read and write to a shared section of memory, or message
passing, in which packets of information in predefined formats are moved between processes
by the operating system.
1.3.6. Error Detection
Error Detection
The operating system needs to be detecting and correcting errors constantly. Errors may occur
in the CPU and memory hardware (such as a memory error or a power failure), in I/O devices
(such as a parity error on disk, a connection failure on a network, or lack of paper in the
printer), and in the user program (such as an arithmetic overflow, an attempt to access an
illegal memory location, or a too-great use of CPU time). For each type of error, the operating
system should take the appropriate action to ensure correct and consistent computing.
Sometimes, it has no choice but to halt the system. At other times, it might terminate an error-
causing process or return an error code to a process for the process to detect and possibly
correct.
Another set of operating system functions exists not for helping the user but rather for ensuring
the efficient operation of the system itself. Systems with multiple users can gain efficiency by
sharing the computer resources among the users.
1.3.7. Resource Allocation
Resource Allocation
When there are multiple users or multiple jobs running at the same time, resources must be
allocated to each of them. The operating system manages many different types of resources.
Some (such as CPU cycles, main memory, and file storage) may have special allocation code,
whereas others (such as I/O devices) may have much more general request and release code. For
1.3.8. Accounting
Accounting
We want to keep track of which users use how much and what kinds of computer resources.
This record keeping may be used for accounting (so that users can be billed) or simply for
accumulating usage statistics. Usage statistics may be a valuable tool for researchers who wish
to reconfigure the system to improve computing services.
1.3.9. Protection and Security
Protection and Security
The owners of information stored in a multiuser or networked computer system may want to
control use of that information. When several separate processes execute concurrently, it should
not be possible for one process to interfere with the others or with the operating system itself.
Protection involves ensuring that all access to system resources is controlled. Security of the
system from outsiders is also important. Such security starts with requiring each user to
authenticate himself or herself to the system, usually by means of a password, to gain access to
system resources. It extends to defending external I/O devices, including network adapters,
from invalid access attempts and to recording all such connections for detection of break-ins. If
a system is to be protected and secure, precautions must be instituted throughout it. A chain is
only as strong as its weakest link.
1.4. User and Operating System Interface
User interface is one of the services of operating system. In this section we are going to looking
at the two main interfaces- command line interpreter and graphical user interface.
1.4.1. Command Interpreters
Some operating systems include the command interpreter in the kernel. Others,
such as Windows and UNIX, treat the command interpreter as a special program that is running
when a job is initiated or when a user first logs on (on interactive systems).
The main function of the command interpreter is to get and execute the next user-specified
command. Many of the commands given at this level manipulate files: create, delete, list, print,
copy, execute, and so on. The MS-DOS and UNIX shells operate in this way.
A second strategy for interfacing with the operating system is through a user friendly graphical user
interface, or GUI. Here, rather than entering commands directly via a command-line interface,
users employ a mouse-based window and- menu system characterized by a desktop metaphor. The
user moves the mouse to position its pointer on images, or icons, on the screen (the desktop) that
represent programs, files, directories, and system functions. Depending on the mouse pointer’s
location, clicking a button on the mouse can invoke a program, select a file or directory—known as
a folder—or pull down a menu that contains commands.
1.4.2. Graphical User Interface
1.5. System Calls
System calls provide an interface to the services made available by an operating system. These
calls are generally available as routines written in C and C++, although certain low-level tasks
(for example, tasks where hardware must be accessed directly) may have to be written using
assembly-language instructions.
1.6. Types of System Calls
1.6.1. Process Control
A running program needs to be able to halt its execution either normally (end()) or abnormally
(abort()). If a system call is made to terminate the currently running program abnormally, or if
the program runs into a problem and causes an error trap, a dump of memory is sometimes taken
and an error message generated. The dump is written to disk and may be examined by a
debugger—a system program designed to aid the programmer in finding and correcting errors,
or bugs—to determine the cause of the problem.
A process or job executing one program may want to load() and execute() another program. This
feature allows the command interpreter to execute a program as directed by, for example, a user
command, the click of a mouse, or a batch command.
Process Control
System calls can be grouped roughly into six major categories: process control, file
manipulation, device manipulation, information maintenance, communications, and
protection.
If both programs continue concurrently, we have created a new job or process to be multi-
programmed. Often, there is a system call specifically for this purpose (create process() or
submit job()).If we create a new job or process, or perhaps even a set of jobs or processes, we
should be able to control its execution. This control requires the ability to determine and reset the
attributes of a job or process, including the job’s priority, its maximum allowable execution time,
and so on (get process attributes () and set process attributes()).We may also want to terminate a
job or process that we created (terminate process()) if we find that it is incorrect or is no longer
needed.
Having created new jobs or processes, we may need to wait for them to finish their execution.
We may want to wait for a certain amount of time to pass (wait time()). More probably, we will
want to wait for a specific event to occur (wait event()). The jobs or processes should then signal
when that event has occurred (signal event()).
1.6.2. File Management
File Management
We first need to be able to create () and delete () files. Either system call requires the name of
the file and perhaps some of the file’s attributes. Once the file is created, we need to open () it
and to use it. We may also read (), write (), or reposition () (rewind or skip to the end of the
file, for example).
1.6.3. Device Management
A process may need several resources to execute—main memory, disk drives, access to files, and
so on. If the resources are available, they can be granted, and control can be returned to the user
process. Otherwise, the process will have to wait until sufficient resources are available.
The various resources controlled by the operating system can be thought of as devices. Some of
these devices are physical devices (for example, disk drives), while others can be thought of as
abstract or virtual devices (for example, files). A system with multiple users may require us to
first request() a device, to ensure exclusive use of it. After we are finished with the device, we
release() it. These functions are similar to the open() and close() system calls for files.
Once the device has been requested (and allocated to us), we can read(), write(), and (possibly)
reposition() the device, just as we can with files.
1.6.4. Information Maintenance
Information Maintenance
Many system calls exist simply for the purpose of transferring information between the user
program and theDevice Management
operating system. For example, most systems have a system call to return the
current_time() and date(). Other system calls may return information about the system, such
as the number of current users, the version number of the operating system, the amount of free
memory or disk space, and so on.
1.6.5. Communication
Communication
There are two common models of inter-process communication: the message passing model
and the shared-memory model.
In the message-passing model, the communicating processes exchange messages with one
another to transfer information. Before communication can take place, a connection must be
opened. The name of the other communicator must be known, be it another process on the same
system or a process on another computer connected by a communications network. Each
computer in a network has a host name by which it is commonly known.
A host also has a network identifier, such as an IP address. Similarly, each process has a process
name, and this name is translated into an identifier by which the operating system can refer to
the process. The get_hostid() and get_processid() system calls do this translation. The
identifiers are then passed to the general purpose open() and close() calls provided by the file
system or to specific open_connection() and close_connection() system calls, depending on the
system’s model of communication. The recipient process usually must give its permission for
communication to take place with an accept_connection() call. The source of the
communication, known as the client, and the receiving daemon, knownas a server, then
exchange messages by using read_message() and write_message() system calls. The
close_connection() call terminates the communication.
In the shared-memory model, processes use shared_memory_create() and
shared_memory_attach() system calls to create and gain access to regions of memory owned
by other processes.
1.6.6. Protection
Protection
Protection provides a mechanism for controlling access to the resources provided by a computer
system.
Typically, system calls providing protection include set_permission() and get_permission(),
which manipulate the permission settings of resources such as files and disks. The allow_user()
and deny_user() system calls specify whether particular users can—or cannot—be allowed
access to certain resources.
1.7. System Programs
System Programs
System programs, also known as system utilities, provide a convenient environment for
program development and execution.
Some of them are simply user interfaces to system calls. Others are considerably more
complex. They can be divided into these categories:
File management. These programs create, delete, copy, rename, print, dump, list, and
generally manipulate files and directories.
Status information. Some programs simply ask the system for the date, time, amount of
available memory or disk space, number of users, or similar status information. Others
are more complex, providing detailed performance, logging, and debugging information.
Typically, these programs format and print the output to the terminal or other output
devices or files or display it in a window of the GUI. Some systems also support a
registry, which is used to store and retrieve configuration information.
File modification. Several text editors may be available to create and modify the content
of files stored on disk or other storage devices. There may also be special commands to
search contents of files or perform transformations of the text.
Programming-language support. Compilers, assemblers, debuggers, and interpreters
for common programming languages (such as C, C++, Java, and PERL) are often
provided with the operating system or available as a separate download.
Program loading and execution. Once a program is assembled or compiled, it must be
loaded into memory to be executed. The system may provide absolute loaders, re-
locatable loaders, linkage editors, and overlay loaders. Debugging systems for either
higher-level languages or machine language are needed as well.
Communications. These programs provide the mechanism for creating virtual
connections among processes, users, and computer systems. They allow users to send
messages to one another’s screens, to browse Web pages, to send e-mail messages, to log
in remotely, or to transfer files from one machine to another.
Background services. All general-purpose systems have methods for launching certain
system-program processes at boot time. Some of these processes terminate after
completing their tasks, while others continue to run until the system is halted. Constantly
running system-program processes are known as services, subsystems, or daemons.
Along with system programs, most operating systems are supplied with programs that are useful
in solving common problems or performing common operations. Such application programs
include Web browsers, word processors and text formatters, spreadsheets, database systems,
compilers, plotting and statistical-analysis packages, and games.
1.8. Operating System Design and Implementation
In this section, we discuss problems we face in designing and implementing an operating
system. There are, of course, no complete solution to such problems, but there are approaches
that have proved successful.
1.8.1. Design Goals
The first problem in designing a system is to define goals and specifications. At the highest level,
the design of the system will be affected by the choice of hardware and the type of system: batch,
time sharing, single user, multiuser, distributed, real time, or general purpose.
Beyond this highest design level, the requirements may be much harder to specify. The
requirements can, however, be divided into two basic groups: user goals and system goals.
Users want certain obvious properties in a system. The system should be convenient to use, easy
to learn and to use, reliable, safe, and fast. Of course, these specifications are not particularly
useful in the system design, since there is no general agreement on how to achieve them.
Specifying and designing an operating system is a highly creative task. Although no textbook
can tell you how to do it, general principles have been developed in the field of software
engineering, and we turn now to a discussion of some of these principles.
1.8.2. Mechanism and Policy
One important principle is the separation of policy from mechanism. Mechanisms determine
how to do something; policies determine what will be done.
For example, the timer construct is a mechanism for ensuring CPU protection, but deciding how
long the timer is to be set for a particular user is a policy decision.
The separation of policy and mechanism is important for flexibility. Policies are likely to change
across places or over time. In the worst case, each change in policy would require a change in the
underlying mechanism. A general mechanism insensitive to changes in policy would be more
desirable. A change in policy would then require redefinition of only certain parameters of the
system.
1.8.3. Implementation
Early operating systems were written in assembly language. Now, although some operating
systems are still written in assembly language, most are written in a higher-level language such
as C or an even higher-level language such as C++.
The advantages of using a higher-level language, or at least a systems implementation language,
for implementing operating systems are the same as those gained when the language is used for
application programs: the code can be written faster, is more compact, and is easier to understand
and debug. In addition, improvements in compiler technology will improve the generated code
for the entire operating system by simple recompilation. Finally, an operating system is far easier
to port—to move to some other hardware—if it is written in a higher-level language.
The only possible disadvantages of implementing an operating system in a higher-level language
are reduced speed and increased storage requirements. This, however, is no longer a major issue
in today’s systems. Although an expert assembly-language programmer can produce efficient
small routines, for large programs a modern compiler can perform complex analysis and apply
sophisticated optimizations that produce excellent code. Modern processors have deep pipelining
and multiple functional units that can handle the details of complex dependencies much more
easily than can the human mind.
1.9. Operating System Structure
A system as large and complex as a modern operating system must be engineered carefully if it
is to function properly and be modified easily. A common approach is to partition the task into
small components, or modules, rather than have one monolithic system. Each of these modules
should be a well-defined portion of the system, with carefully defined inputs, outputs, and
functions.
1.9.1. Simple Structure
Simple Structure
Many operating systems do not have well-defined structures. Frequently, such systems started as
small, simple, and limited systems and then grew beyond their original scope. MS-DOS is an
example of such a system. It was originally designed and implemented by a few people who had
no idea that it would become so popular. It was written to provide the most functionality in the
least space, so it was not carefully divided into modules.
In MS-DOS, the interfaces and levels of functionality are not well separated. For instance,
application programs are able to access the basic I/O routines to write directly to the display and
disk drives. Such freedom leaves MS-DOS vulnerable to errant (or malicious) programs, causing
entire system crashes when user programs fail.
1.9.2. Layered Approach
Layered Approach
With proper hardware support, operating systems can be broken into pieces that are smaller
and more appropriate than those allowed by the original MS-DOS and UNIX systems. The
operating system can then retain much greater control over the computer and over the
applications that make use of that computer. Implementers have more freedom in changing
the inner workings of the system and in creating modular operating systems. Under a top-
down approach, the overall functionality and features are determined and are separated into
components. Information hiding is also important, because it leaves programmers free to
implement the low-level routines as they see fit, provided that the external interface of the
routine stays unchanged and that the routine itself performs the advertised task.
A system can be made modular in many ways. One method is the layered approach, in
which the operating system is broken into a number of layers (levels). The bottom layer (layer
0) is the hardware; the highest (layer N) is the user interface. Figure 1 shows layered operating
system.
Figure 2: Layered Operating System
1.9.3. Modules
Modules
Perhaps the best current methodology for operating-system design involves using loadable
kernel modules. Here, the kernel has a set of core components and links in additional services
via modules, either at boot time or during run time. This type of design is common in modern
implementations of UNIX, such as Solaris, Linux, and Mac OS X, as well as Windows.
The idea of the design is for the kernel to provide core services while other services are
implemented dynamically, as the kernel is running. Figure 3 shows a module-based OS.
Figure 3 Module based OS in Solaris
1.10. System Boot
System Boot
After an operating system is generated, it must be made available for use by the hardware. But
how does the hardware know where the kernel is or how to load that kernel? The procedure of
starting a computer by loading the kernel is known as booting the system. On most computer
systems, a small piece of code known as the bootstrap program or bootstrap loader locates the
kernel, loads it into main memory, and starts its execution.
The bootstrap program can perform a variety of tasks. Usually, one task is to run diagnostics to
determine the state of the machine. If the diagnostics pass, the program can continue with the
booting steps. It can also initialize all aspects of the system, from CPU registers to device
controllers and the contents of main memory. Sooner or later, it starts the operating system.
Now that the full bootstrap program has been loaded, it can traverse the file system to find the
operating system kernel, load it into memory, and start its execution. It is only at this point that
the system is said to be running.
1.11. Self-test Questions
1. Explain operating services to the system
2. What is the purpose of the system call?
3. What is the purpose of system program?
1.12. Summary
Operating system provides major services to both users and the system. Users of the
computer are presented with methods of interacting with the computer through command line
interface or the most common method of graphical user interface. The structure of the operating
system matters a lot when it comes to efficient functioning of the computer. Modular-based structure
is the most implemented method. The booting of the operating system involves the firmware
executing the instructions of the kernel of the operating system. Until this is done the computer is
said to be off.
1.13. Reference
Reference
i. William, S. (2017). Operating Systems: Internals and Design Principles
(9th ed.). Pearson ISBN– 10: 0134670957
ii. Andrew, S. T, Herbert B. (2014). Modern Operating Systems (4th Ed.).
Pearson. ISBN– 10: 013359162X
iii. Abraham, S. (2012). Operating System Concepts (9th ed.), ISBN– 13:
978– 1118063330.