2 of 79

Chapter 2: Operating-System Structures

Operating System Services
User Operating System Interface
System Calls
Types of System Calls
System Programs
Operating System Design and Implementation
Operating System Structure
Operating System Debugging
Operating System Generation
System Boot

2.2

Operating System Concepts – 9^th Edition

3 of 79

Objectives

To describe the services an operating system provides to users, processes, and other systems
To discuss the various ways of structuring an operating system
To explain how operating systems are installed and customized and how they boot

2.3

Operating System Concepts – 9^th Edition

4 of 79

Operating System Services

Operating systems provide an environment for execution of programs and services to programs and users
One set of operating-system services provides functions that are helpful to the user:
User interface - Almost all operating systems have a user interface (UI). This interface can take several forms.

One is Command-Line (CLI) which uses text commands and a method for creating 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 control those commands are entered into files and those files are executed.
Most commonly, a Graphics User Interface (GUI) is used. Here, the interface is a window system with a pointing device to direct I/O, chose from menus, and make selections and keyboard to enter the text. Some systems provide two or all three of the variations.

2.4

Operating System Concepts – 9^th Edition

5 of 79

Operating System Services

Program execution - The system must be able to load a program into memory and to run that program, end execution, either normally or abnormally (indicating error)
I/O operations - A running program may require I/O, which may involve a file or an I/O device. For efficiency and protection, users usually cannot control I/O devices directly. Therefore, the operating system must provide a means to do I/O.
File-system manipulation - The file system is of particular interest. Programs need to read and write files and directories, create and delete them, search them, list file Information, permission management.

2.5

Operating System Concepts – 9^th Edition

6 of 79

Operating System Services (Cont.)

Communications – Processes may exchange information, on the same computer or between computers over a network. Communications may be via shared memory or through message passing (packets moved by the OS)
Error detection – OS needs to be constantly aware of possible errors

May occur in the CPU and memory hardware, in I/O devices, in user program
For each type of error, OS should take the appropriate action to ensure correct and consistent computing
Debugging facilities can greatly enhance the user’s and programmer’s abilities to efficiently use the system

2.6

Operating System Concepts – 9^th Edition

7 of 79

Operating System Services (Cont.)

Another set of OS functions exists for ensuring the efficient operation of the system itself via resource sharing

Resource allocation - When multiple users or multiple jobs running concurrently, resources must be allocated to each of them

Many types of resources - CPU cycles, main memory, file storage, I/O devices.

Accounting - To keep track of which users use how much and what kinds of computer resources
Protection and security - The owners of information stored in a multiuser or networked computer system may want to control use of that information, concurrent processes should not interfere with each other

Protection involves ensuring that all access to system resources is controlled
Security of the system from outsiders requires user authentication, extends to defending external I/O devices from invalid access attempts

2.7

Operating System Concepts – 9^th Edition

8 of 79

A View of Operating System Services

Figure: A view of operating system services.

2.8

Operating System Concepts – 9^th Edition

9 of 79

User Operating System Interface

As mentioned earlier that there are several ways for users to interface with the operating system. Here, we discuss two fundamental approaches.
One provides a command-line interface, or command interpreter, that allows users to directly enter commands to be performed by the operating system.
The other allows users to interface with the operating system via a graphical user interface, or GUI.

2.9

Operating System Concepts – 9^th Edition

10 of 79

User Operating System Interface

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).
On systems with multiple command interpreters to choose from, the interpreters are known as shells.
For example, on UNIX and Linux systems, a user may choose among several different shells, including the Bourne shell, C shell, Bourne-Again shell, Korn shell, and others. Third-party shells and free user-written shells are also available.

2.10

Operating System Concepts – 9^th Edition

11 of 79

User Operating System Interface

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.
These commands can be implemented in two general ways.
In one approach, the command interpreter itself contains the code to execute the command. For example, a command to delete a file may cause the command interpreter to jump to a section of its code that sets up the parameters and makes the appropriate system call.
An alternative approach—used by UNIX, among other operating systems —implements most commands through system programs. In this case, the command interpreter does not understand the command in any way; it merely uses the command to identify a file to be loaded into memory and executed. Thus, the UNIX command to delete a file rm file.txt, would search for a file called rm, load the file into memory, and execute it with the parameter file.txt.

2.11

Operating System Concepts – 9^th Edition

12 of 79

Bourne Shell Command Interpreter

2.12

Operating System Concepts – 9^th Edition

13 of 79

User Operating System Interface - GUI

Graphical User Interfaces:

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.
Graphical user interfaces first appeared due in part to research taking place in the early 1970s at Xerox PARC research facility. The first GUI appeared on the Xerox Alto computer in 1973.
However, graphical interfaces became more widespread with the advent of Apple Macintosh computers in the 1980s.

2.13

Operating System Concepts – 9^th Edition

14 of 79

Touchscreen Interfaces

Touchscreen devices require new interfaces

Mouse not possible or not desired
Actions and selection based on gestures
Virtual keyboard for text entry

Voice commands.

2.14

Operating System Concepts – 9^th Edition

15 of 79

The Mac OS X GUI

2.15

Operating System Concepts – 9^th Edition

16 of 79

User Operating System Interface - GUI

Choice of Interface

The choice of whether to use a command-line or GUI interface is mostly one of personal preference. System administrators who manage computers and power users who have deep knowledge of a system frequently use the command-line interface.
The user interface can vary from system to system and even from user to user within a system.

2.16

Operating System Concepts – 9^th Edition

17 of 79

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.
let’s first use an example to illustrate how system calls are used:
writing a simple program to read data from one file and copy them to another file. The first input that the program will need is the names of the two files: the input file and the output file.
These names can be specified in many ways, depending on the operating-system design. One approach is for the program to ask the user for the names.

2.17

Operating System Concepts – 9^th Edition

18 of 79

System Calls

In an interactive system, this approach will require a sequence of system calls, first to write a prompting message on the screen and then to read from the keyboard the characters that define the two files.
On mouse-based and icon-based systems, a menu of file names is usually displayed in a window.
The user can then use the mouse to select the source name, and a window can be opened for the destination name to be specified. This sequence requires many I/O system calls.
Once the two file names have been obtained, the program must open the input file and create the output file. Each of these operations requires another system call.
Possible error conditions for each operation can require additional system calls. When the program tries to open the input file, for example, it may find that there is no file of that name or that the file is protected against access.

2.18

Operating System Concepts – 9^th Edition

19 of 79

System Calls

In these cases, the program should print a message on the console (another sequence of system calls) and then terminate abnormally (another system call).
If the input file exists, then we must create a new output file.
We may find that there is already an output file with the same name. This situation may cause the program to abort (a system call), or we may delete the existing file (another system call) and create a new one (yet another system call).
Another option, in an interactive system, is to ask the user (via a sequence of system calls to output the prompting message and to read the response from the terminal) whether to replace the existing file or to abort the program.
When both files are set up, we enter a loop that reads from the input file (a system call) and writes to the output file (another system call). Each read and write must return status information regarding various possible error conditions.

2.19

Operating System Concepts – 9^th Edition

20 of 79

System Calls

On input, the program may find that the end of the file has been reached or that there was a hardware failure in the read (such as a parity error).
The write operation may encounter various errors, depending on the output device (for example, no more disk space).
Finally, after the entire file is copied, the program may close both files (another system call), write a message to the console or window (more system calls), and finally terminate normally (the final system call).

2.20

Operating System Concepts – 9^th Edition

21 of 79

Example of System Calls

System call sequence to copy the contents of one file to another file

Figure: Example of how system calls are used.

2.21

Operating System Concepts – 9^th Edition

22 of 79

System Calls

As you can see, even simple programs may make heavy use of the operating system. Frequently, systems execute thousands of system calls per second. Most programmers never see this level of detail, however.
Typically, application developers design programs according to an application programming interface (API).
The API specifies a set of functions that are available to an application programmer, including the parameters that are passed to each function and the return values the programmer can expect.
Three of the most common APIs available to application programmers are the Windows API for Windows systems, the POSIX API for POSIX-based systems (which include virtually all versions of UNIX, Linux, and Mac OSX), and the Java API for programs that run on the Java virtual machine.

2.22

Operating System Concepts – 9^th Edition

23 of 79

Example of Standard API

2.23

Operating System Concepts – 9^th Edition

24 of 79

System Calls

For most programming languages, the run-time support system (a set of functions built into libraries included with a compiler) provides a system call interface that serves as the link to system calls made available by the operating system.
The system-call interface intercepts function calls in the API and invokes the necessary system calls within the operating system.
Typically, a number is associated with each system call, and the system-call interface maintains a table indexed according to these numbers.
The system call interface then invokes the intended system call in the operating-system kernel and returns the status of the system call and any return values.
The caller need know nothing about how the system call is implemented or what it does during execution. Rather, the caller need only obey the API and understand what the operating system will do as a result of the execution of that system call.

2.24

Operating System Concepts – 9^th Edition

25 of 79

System Call Implementation

Thus, most of the details of the operating-system interface are hidden from the programmer by the API and are managed by the run-time support library.
System calls occur in different ways, depending on the computer in use. Often, more information is required than simply the identity of the desired system call.
The exact type and amount of information vary according to the particular operating system and call. For example, to get input, we may need to specify the file or device to use as the source, as well as the address and length of the memory buffer into which the input should be read.

2.25

Operating System Concepts – 9^th Edition

26 of 79

API – System Call – OS Relationship

Figure: The handling of a user application invoking the open() system call.

2.26

Operating System Concepts – 9^th Edition

27 of 79

System Call Parameter Passing

Often, more information is required than simply identity of desired system call

Exact type and amount of information vary according to OS and call

Three general methods used to pass parameters to the OS

Simplest: pass the parameters in registers

In some cases, may be more parameters than registers

Parameters stored in a block, or table, in memory, and address of block passed as a parameter in a register

This approach taken by Linux and Solaris

Parameters placed, or pushed, onto the stack by the program and popped off the stack by the operating system
Block and stack methods do not limit the number or length of parameters being passed

2.27

Operating System Concepts – 9^th Edition

28 of 79

Parameter Passing via Table

Figure: Passing of parameters as a table.

2.28

Operating System Concepts – 9^th Edition

29 of 79

Types of System Calls

System calls can be grouped roughly into six major categories:
Process Control,
File Manipulation,
Device Manipulation,
Information Maintenance,
Communications, and
Protection.

2.29

Operating System Concepts – 9^th Edition

30 of 79

Types of System Calls

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.
Under either normal or abnormal circumstances, the operating system must transfer control to the invoking command interpreter. The command interpreter then reads the next command.
In an interactive system, the command interpreter simply continues with the next command; it is assumed that the user will issue an appropriate command to respond to any error.
In a GUI system, a pop-up window might alert the user to the error and ask for guidance.
In a batch system, the command interpreter usually terminates the entire job and continues with the next job.

2.30

Operating System Concepts – 9^th Edition

31 of 79

Types of System Calls

Process Control

end, abort
load, execute
create process, terminate process
get process attributes, set process attributes
wait for time
wait event, signal event
allocate and free memory
A process or job executing one program may want to load() and execute() another program.
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.

2.31

Operating System Concepts – 9^th Edition

32 of 79

Types of System Calls

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). Finally, we need to close() the file, indicating that we are no longer using it.
In addition, for either files or directories, we need to be able to determine the values of various attributes and perhaps to reset them if necessary. File attributes include the file name, file type, protection codes, accounting information, and so on.
At least two system calls, get file attributes() and set file attributes(), are required for this function. Some operating systems provide many more calls, such as calls for file move() and copy().

2.32

Operating System Concepts – 9^th Edition

33 of 79

Types of System Calls

File Management

request device, release device
read, write, reposition
get device attributes, set device attributes
logically attach or detach devices

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.
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.

2.33

Operating System Concepts – 9^th Edition

34 of 79

Types of System Calls

Device Management

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.

Device management

request device, release device
read, write, reposition
get device attributes, set device attributes
logically attach or detach devices

2.34

Operating System Concepts – 9^th Edition

35 of 79

Types of System Calls

Information Maintenance

Many system calls exist simply for the purpose of transferring information between the user program and the 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.
Another set of system calls is helpful in debugging a program. Many systems provide system calls to dump() memory. This provision is useful for debugging.
Many operating systems provide a time profile of a program to indicate the amount of time that the program executes at a particular location or set of locations.

2.35

Operating System Concepts – 9^th Edition

36 of 79

Types of System Calls

In addition, the operating system keeps information about all its processes, and system calls are used to access this information. Generally, calls are also used to reset the process information (get process attributes() and set process attributes()).
Information maintenance

get time or date, set time or date
get system data, set system data
get and set process, file, or device attributes

2.36

Operating System Concepts – 9^th Edition

37 of 79

Types of System Calls

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.
Messages can be exchanged between the processes either directly or indirectly through a common mailbox. Before communication can take place, a connection must be opened.
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.

Communications

create, delete communication connection
send, receive messages
transfer status information
attach or detach remote devices

2.37

Operating System Concepts – 9^th Edition

38 of 79

Types of System Calls

Protection

Protection provides a mechanism for controlling access to the resources provided by a computer system.
Historically, protection was a concern only on multi-programmed computer systems with several users.
However, with the advent of networking and the Internet, all computer systems, from servers to mobile handheld devices, must be concerned with protection.
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.

2.38

Operating System Concepts – 9^th Edition

39 of 79

Types of System Calls (Cont.)

Protection

Control access to resources
Get and set permissions
Allow and deny user access

2.39

Operating System Concepts – 9^th Edition

40 of 79

Examples of Windows and Unix System Calls

2.40

Operating System Concepts – 9^th Edition

41 of 79

Standard C Library Example

C program invoking printf() library call, which calls write() system call

2.41

Operating System Concepts – 9^th Edition

42 of 79

Example: MS-DOS

Single-tasking
Shell invoked when system booted
Simple method to run program

No process created

Single memory space
Loads program into memory, overwriting all but the kernel
Program exit -> shell reloaded

At system startup running a program

2.42

Operating System Concepts – 9^th Edition

43 of 79

Example: FreeBSD

Unix variant
Multitasking
User login -> invoke user’s choice of shell
Shell executes fork() system call to create process

Executes exec() to load program into process
Shell waits for process to terminate or continues with user commands

Process exits with:

code = 0 – no error
code > 0 – error code

2.43

Operating System Concepts – 9^th Edition

44 of 79

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.
They can be divided into these categories:

File manipulation
Status information sometimes stored in a File modification
Programming language support
Program loading and execution
Communications
Background services
Application programs

2.44

Operating System Concepts – 9^th Edition

45 of 79

System Programs

File management - These programs create, delete, copy, rename, print, dump, list, and generally manipulate files and directories.
Status information

Some ask the system for info - date, time, amount of available memory, disk space, number of users
Others provide detailed performance, logging, and debugging information
Typically, these programs format and print the output to the terminal or other output devices
Some systems implement a registry - 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.
Special commands to search contents of files or perform transformations of the text

2.45

Operating System Concepts – 9^th Edition

46 of 79

System Programs (Cont.)

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.
Program loading and execution- Absolute loaders, relocatable loaders, linkage editors, and overlay-loaders, debugging systems for higher-level and machine language
Communications - Provide the mechanism for creating virtual connections among processes, users, and computer systems.
Allow users to send messages to one another’s screens, browse web pages, send electronic-mail messages, log in remotely, transfer files from one machine to another.
Background Services

Launch at boot time

Some for system startup, then terminate
Some from system boot to shutdown

Provide facilities like disk checking, process scheduling, error logging, printing

2.46

Operating System Concepts – 9^th Edition

47 of 79

System Programs (Cont.)

Constantly running system-program processes are known as services, subsystems, or daemons.

Application programs

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.

2.47

Operating System Concepts – 9^th Edition

48 of 79

Operating System Design and Implementation

Design and Implementation of OS not “solvable”, but some approaches have proven successful
Internal structure of different Operating Systems can vary widely
Start the design by defining goals and specifications
Affected by choice of hardware, type of system
User goals and System goals

User goals – operating system should be convenient to use, easy to learn, reliable, safe, and fast
System goals – operating system should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient

2.48

Operating System Concepts – 9^th Edition

49 of 79

Operating System Design and Implementation (Cont.)

Mechanisms and Policies

Important principle to separate

Policy: What will be done? �Mechanism: How to do it?

Mechanisms determine how to do something, policies decide what will be done.
The separation of policy from mechanism is a very important principle, it allows maximum flexibility if policy decisions are to be changed later. 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.
Specifying and designing an OS is highly creative task of software engineering.

2.49

Operating System Concepts – 9^th Edition

50 of 79

Operating System Design and Implementation (Cont.)

Mechanisms and Policies

Important principle to separate

Policy: What will be done? �Mechanism: How to do it?

Mechanisms determine how to do something, policies decide what will be done.
The separation of policy from mechanism is a very important principle, it allows maximum flexibility if policy decisions are to be changed later. 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.
Specifying and designing an OS is highly creative task of software engineering.

2.50

Operating System Concepts – 9^th Edition

51 of 79

Operating System Design and Implementation (Cont.)

Mechanisms and Policies

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 change in policy would then require redefinition of only certain parameters of the system.
Microkernel-based operating systems take the separation of mechanism and policy to one extreme by implementing a basic set of primitive building blocks.
These blocks are almost policy free, allowing more advanced mechanisms and policies to be added via user-created kernel modules or user programs themselves.
Policy decisions are important for all resource allocation. Whenever it is necessary to decide whether or not to allocate a resource, a policy decision must be made. Whenever the question is how rather than what, it is a mechanism that must be determined.

2.51

Operating System Concepts – 9^th Edition

52 of 79

Implementation

Once an operating system is designed, it must be implemented. Because operating systems are collections of many programs, written by many people over a long period of time, it is difficult to make general statements about how they are implemented.
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.

2.52

Operating System Concepts – 9^th Edition

53 of 79

Implementation

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.
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.

2.53

Operating System Concepts – 9^th Edition

54 of 79

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.

Simple structure – MS-DOS

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 written to provide the most functionality in the least space, so it was not carefully divided into modules.

2.54

Operating System Concepts – 9^th Edition

55 of 79

Simple Structure -- MS-DOS

Figure 2.11 MS-DOS layer structure.

2.55

Operating System Concepts – 9^th Edition

56 of 79

Operating System Structure

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.
Because the Intel 8088 for which it was written provides no dual mode and no hardware protection, the designers of MS-DOS had no choice but to leave the base hardware accessible.

2.56

Operating System Concepts – 9^th Edition

57 of 79

Non Simple Structure -- UNIX

Another example of limited structuring is the original UNIX operating system. Like MS-DOS, UNIX initially was limited by hardware functionality. It consists of two separable parts: the kernel and the system programs.
The kernel is further separated into a series of interfaces and device drivers, which have been added and expanded over the years as UNIX has evolved.
Everything below the system-call interface and above the physical hardware is the kernel. The kernel provides the file system, CPU scheduling, memory management, and other operating-system functions through system calls.
This monolithic structure was difficult to implement and maintain. It had a distinct performance advantage, however: there is very little overhead in the system call interface or in communication within the kernel.

2.57

Operating System Concepts – 9^th Edition

58 of 79

Traditional UNIX System Structure

Beyond simple but not fully layered

2.58

Operating System Concepts – 9^th Edition

59 of 79

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.
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).

2.59

Operating System Concepts – 9^th Edition

60 of 79

Layered Approach

The bottom layer (layer 0) is the hardware; the highest (layer N) is the user interface.
A typical operating-system layer—say, layer M—consists of data structures and a set of routines that can be invoked by higher-level layers. Layer M, in turn, can invoke operations on lower-level layers.
The main advantage of the layered approach is simplicity of construction and debugging. The layers are selected so that each uses functions (operations) and services of only lower-level layers.
This approach simplifies debugging and system verification. The first layer can be debugged without any concern for the rest of the system.
Once the first layer is debugged, its correct functioning can be assumed while the second layer is debugged, and so on.
If an error is found during the debugging of a particular layer, the error must be on that layer, because the layers below it are already debugged.

2.60

Operating System Concepts – 9^th Edition

61 of 79

Layered Approach

2.61

Operating System Concepts – 9^th Edition

62 of 79

Layered Approach

The design and implementation of the system are simplified.
Each layer is implemented only with operations provided by lower-level layers.
A layer does not need to know how these operations are implemented; it needs to know only what these operations do.
Hence, each layer hides the existence of certain data structures, operations, and hardware from higher-level layers.
The major difficulty with the layered approach involves appropriately defining the various layers.
Another problem with layered implementations is that they tend to be less efficient than other types.

2.62

Operating System Concepts – 9^th Edition

63 of 79

Microkernel System Structure

In the mid-1980s, researchers at Carnegie Mellon University developed an operating system called Mach that modularized the kernel using the microkernel approach.
This method structures the operating system by removing all nonessential components from the kernel and implementing them as system and user-level programs.
There is little consensus regarding which services should remain in the kernel and which should be implemented in user space.
Typically, however, microkernels provide minimal process and memory management, in addition to a communication facility.
The main function of the microkernel is to provide communication between the client program and the various services that are also running in user space.
Communication is provided through message passing

2.63

Operating System Concepts – 9^th Edition

64 of 79

Figure: Architecture of a typical microkernel.

2.64

Operating System Concepts – 9^th Edition

65 of 79

Microkernel System Structure

One benefit of the microkernel approach is that it makes extending the operating system easier.
All new services are added to user space and consequently do not require modification of the kernel.
Operating system is easier to port from one hardware design to another.
The microkernel also provides more security and reliability, since most services are running as user rather than kernel processes.
If a service fails, the rest of the operating system remains untouched.
Unfortunately, the performance of microkernels can suffer due to increased system-function overhead.

2.65

Operating System Concepts – 9^th Edition

66 of 79

Modules

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.
Linking services dynamically is preferable to adding new features directly to the kernel, which would require recompiling the kernel every time a change was made.
The overall result resembles a layered system in that each kernel section has defined, protected interfaces; but it is more flexible than a layered system, because any module can call any other module.

2.66

Operating System Concepts – 9^th Edition

67 of 79

Solaris Modular Approach

2.67

Operating System Concepts – 9^th Edition

68 of 79

Modules

The approach is also similar to the microkernel approach in that the primary module has only core functions and knowledge of how to load and communicate with other modules; but it is more efficient, because modules do not need to invoke message passing in order to communicate.
The Solaris operating system structure, shown in Figure, is organized around a core kernel with seven types of loadable kernel modules:

1. Scheduling classes

2. File systems

3. Loadable system calls

4. Executable formats

5. STREAMS modules

6. Miscellaneous

7. Device and bus drivers

2.68

Operating System Concepts – 9^th Edition

69 of 79

Hybrid Systems

Most modern operating systems are actually not one pure model

Hybrid combines multiple approaches to address performance, security, usability needs
Linux and Solaris kernels in kernel address space, so monolithic, plus modular for dynamic loading of functionality
Windows mostly monolithic, plus microkernel for different subsystem personalities

Apple Mac OS X hybrid, layered, Aqua UI plus Cocoa programming environment

Below is kernel consisting of Mach microkernel and BSD Unix parts, plus I/O kit and dynamically loadable modules (called kernel extensions)

2.69

Operating System Concepts – 9^th Edition

70 of 79

Mac OS X Structure

2.70

Operating System Concepts – 9^th Edition

71 of 79

iOS

Apple mobile OS for iPhone, iPad

Structured on Mac OS X, added functionality
Does not run OS X applications natively

Also runs on different CPU architecture (ARM vs. Intel)

Cocoa Touch Objective-C API for developing apps
Media services layer for graphics, audio, video
Core services provides cloud computing, databases
Core operating system, based on Mac OS X kernel

2.71

Operating System Concepts – 9^th Edition

72 of 79

Android

Developed by Open Handset Alliance (mostly Google)

Open Source

Similar stack to IOS
Based on Linux kernel but modified

Provides process, memory, device-driver management
Adds power management

Runtime environment includes core set of libraries and Dalvik virtual machine

Apps developed in Java plus Android API

Java class files compiled to Java bytecode then translated to executable than runs in Dalvik VM

Libraries include frameworks for web browser (webkit), database (SQLite), multimedia, smaller libc

2.72

Operating System Concepts – 9^th Edition

73 of 79

Android Architecture

2.73

Operating System Concepts – 9^th Edition

74 of 79

Operating System Generation

It is possible to design, code, and implement an operating system specifically for one machine at one site.
More commonly, however, operating systems are designed to run on any of a class of machines at a variety of sites with a variety of peripheral configurations.
The system must then be configured or generated for each specific computer site, a process sometimes known as system generation SYSGEN.
The operating system is normally distributed on disk, on CD-ROM or DVD-ROM, or as an “ISO” image, which is a file in the format of a CD-ROM or DVD-ROM.
This SYSGEN program reads from a given file, or asks the operator of the system for information concerning the specific configuration of the hardware system, or probes the hardware directly to determine what components are there.

2.74

Operating System Concepts – 9^th Edition

75 of 79

Operating System Generation

The following kinds of information must be determined.

What CPU is to be used? What options are installed? (extended instruction sets, floating point arithmetic, and so on). For multiple CPU systems, each CPU may be described.
How will the boot disk be formatted? How many sections, or “partitions,” will it be separated into, and what will go into each partition?
How much memory is available?
What devices are available? The system will need to know how to address each device (the device number), the device interrupt number, the device’s type and model, and any special device characteristics.
What operating-system options are desired, or what parameter values are to be used? These options or values might include how many buffers of which sizes should be used, what type of CPU-scheduling algorithm is desired, what the maximum number of processes to be supported is, and so on.

2.75

Operating System Concepts – 9^th Edition

76 of 79

Operating System Generation

Once this information is determined, it can be used in several ways.
At one extreme, a system administrator can use it to modify a copy of the source code of the operating system.
Data declarations, initializations, and constants, along with conditional compilation, produce an output-object version of the operating system that is tailored to the system described.
At a slightly less tailored level, the system description can lead to the creation of tables and the selection of modules from a precompiled library.

2.76

Operating System Concepts – 9^th Edition

77 of 79

System Boot

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.
Some computer systems, such as PCs, use a two-step process in which a simple bootstrap loader fetches a more complex boot program from disk, which in turn loads the kernel.
When a CPU receives a reset event—for instance, when it is powered up or rebooted—the instruction register is loaded with a predefined memory location, and execution starts there.
At that location is the initial bootstrap program. This program is in the form of read-only memory (ROM), because the RAM is in an unknown state at system startup.
ROM is convenient because it needs no initialization and cannot easily be infected by a computer virus.

2.77

Operating System Concepts – 9^th Edition

78 of 79

System Boot

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.
Storing the operating system in ROM is suitable for small operating systems, simple supporting hardware, and rugged operation.
A problem with this approach is that changing the bootstrap code requires changing the ROM hardware chips.
Some systems resolve this problem by using erasable programmable read-only memory (EPROM), which is read only except when explicitly given a command to become writable.

2.78

Operating System Concepts – 9^th Edition

1 of 79

2 of 79

3 of 79

4 of 79

5 of 79

6 of 79

7 of 79

8 of 79

9 of 79

10 of 79

11 of 79

12 of 79

13 of 79

14 of 79

15 of 79

16 of 79

17 of 79

18 of 79

19 of 79

20 of 79

21 of 79

22 of 79

23 of 79

24 of 79

25 of 79

26 of 79

27 of 79

28 of 79

29 of 79

30 of 79

31 of 79

32 of 79

33 of 79

34 of 79

35 of 79

36 of 79

37 of 79

38 of 79

39 of 79

40 of 79

41 of 79

42 of 79

43 of 79

44 of 79

45 of 79

46 of 79

47 of 79

48 of 79

49 of 79

50 of 79

51 of 79

52 of 79

53 of 79

54 of 79

55 of 79

56 of 79

57 of 79

58 of 79

59 of 79

60 of 79

61 of 79

62 of 79

63 of 79

64 of 79

65 of 79

66 of 79

67 of 79

68 of 79

69 of 79

70 of 79

71 of 79

72 of 79

73 of 79

74 of 79

75 of 79

76 of 79

77 of 79

78 of 79

79 of 79