CE Operating Systems Lecture 3 Overview of OS functions and structure

In this lecture we shall give an overview of 1. The functions of an operating system 2. Operating system components and services 3. Different models of the structure of an operating system

What do programs need in order to run? CPU to execute the program instructions Memory to hold copies of the program instructions data to be used by program Access to disk to hold program and data between runs of the program Access to input devices Access to output devices

What do Operating Systems do? As we saw last week in a operating system programs are not allowed direct access to any of the resources except CPU and memory and even then the use has limits placed on it. Thus 1. OS handles requests from programs for various resources to do things e.g. input or output something and enforces the limits placed on the use of the CPU and memory.

What do Operating Systems do? (cont.) Resources cannot be used by different programs at the same time. Thus 2. OS needs to control sharing of resources between programs so that they do not interfere with each other Programs sometimes need to communicate with each other. Thus 3. OS needs to provide a mechanism by which one program can communicate with another.

What do Operating Systems do? (cont.) The users need to be able to tell the OS what programs to run, when and with what data. Thus 4. OS needs to provide some form of interface to allow users to issue commands to the OS.

Functions of OS So functions of OS have to do with: 1. Handling requests 2. Sharing resources 3. Communication 4. User interface

Function 1 - system call interface and device drivers In order to fulfil function 1 the OS must provide a mechanism by which programs can pass on requests to the OS to do something for the program. This is the system call (remember from last week - software interrupt).

System call interface and device drivers (Cont.) To allow a program to make a wide variety of requests then the OS needs to provide a large variety of system calls. This is the system call interface, often called the Application Programmer’s Interface (API). This is essentially a library of code modules that perform various operations on behalf of the application program

System call interface and device drivers (Cont.) To get various hardware components (e.g. I/O or disk) to do what the OS wants them to do (on behalf of the user’s program) then the OS must have programs of its own that tell the hardware what to do i.e. to manage and control the hardware. These are the device drivers.

Function 2 - Schedulers, mutual exclusion, deadlock and security In order to fulfil function 2, for each type of resource, the OS needs to share the use of the resource between the different programs that want to use it. To do this fairly between the different programs it must allocate resources to a program i.e. give it the right to use a resource and then schedule the use of the resource between the different programs.

Schedulers, mutual exclusion, deadlock and security (Cont.) Thus for each different resource the OS will have a program called a scheduler that determines which program gets what resource next.

Schedulers, mutual exclusion, deadlock and security (Cont.) OS also needs to ensure that the use of resources by programs is safe. Safe from software faults and malicious action and safe from errors that the operating system may produce as a result of its actions. Thus the OS needs to provide software that is part of OS for security and protection to prevent unauthorised use of resources and to monitor its own actions for safety e.g. management of deadlock.

Schedulers, mutual exclusion, deadlock and security (Cont.) OS must also ensure that when a program is using a resource the earlier or later use of that resource by another program does not corrupt or interfere with that program. This requires the OS to provide the programs with software that is part of OS that implements the notion of an atomic action (also known as mutual exclusion – stops programs from executing some code, until other programs have finished executing the same code).

Function 3 - Interprocess communication and co-ordination In order to fulfil function 3, the OS must provide a mechanism by which programs can communicate with each other. This is called interprocess communication. The OS may provide a number of different ways of doing this.

Interprocess communication and co-ordination (Cont.) Interprocess communication then allows user programs to co-operate with each other and with the OS in order to complete some task. This co-ordination of activities sometimes requires synchronisation of actions between programs.

Function 4 - User interface OS needs software that is part of OS that can process user requests and initiate the execution of programs on the user’s behalf - commands are given to the operating system by control actions (mouse clicks) or typed commands

User interface (Cont.) Since the users can permanently store programs and data on the computer then the OS must provide software that is part of OS that the user can use to manage the files that the user owns.

User interface (Cont.) The program that receives, interprets and executes the next command action/statement may be: command-line interpreter or shell - to process typed commands Graphical User Interface (Windows, Icons, Menus, Pointers) based system - to process control actions

OS components Thus OS components consist of a number of programs that have the tasks described in the previous slides: System call interface Device drivers Schedulers for each type of resource Deadlock management Security & protection Implementation of mutual exclusion Interprocess communication and co-ordination User interface

System Calls System calls provide the interface between a running program and the operating system. In assembly language – they are implemented by traps or software interrupts In programming languages that were developed to replace assembly language for systems programming (e.g., C, Perl, BCPL), they are implemented like calls to library routines. The system calls are compiled into software interrupts

System Programs System programs are provided by system to allow users to carry out O/S maintenance functions and program development directly. Typical functions include, File/directory management Programming language support Program loading and execution Communications

System Programs (Cont.) Most users’ view of the operating system is defined by system programs, not the actual system calls.

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

Mechanisms and Policies 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.

System Implementation Originally written in assembly language, operating systems now largely written in higher level languages, except for small amount of code which is still in assembly language Code written in a high level language: can be written faster. is easier to understand and debug.

System Implementation (Cont.) An operating system is far easier to port (move to some other hardware platform) if it is written in a high level language.

System Generation Operating systems are designed to run on any of a class of machines; the system must be configured for each specific computer site or machine. A system generation program obtains information concerning the specific configuration of the hardware system. Then it could either, Recompile whole kernel, or link together precompiled components

Operating system models An operating system model is a framework that characterises how the various system features and services are combined together into a structure. Essentially it defines a general approach to the structure of the OS Popular models: Monolithic operating systems Layered operating systems Client/Server operating systems

Monolithic operating systems Application Program Application Program System Services User Mode Kernel Mode hardware OS Procedures

Monolithic operating systems operating system code organised as a set of procedures each procedure can call any other procedures all operating system data structures are visible to all operating system code code in procedures are dependent upon knowledge of structure/operation of other procedures

Monolithic operating systems (Cont.) very difficult to change code typical of smaller and older operating systems e.g. MS-Dos and Unix

Layered operating systems Application Program Application Program System Services User Mode Kernel Mode File System Memory and I/O Device Management Process Management Hardware

Layered operating systems operating system code is organised into a series of layers each layer is responsible for performing some given task each layer provides an interface - set of functions that other layers can call can only access functionality of given layer through calls to functions that make up the interface

Layered operating systems (Cont.) code in one layer can only access interface functions of lower layers much better structure - easier to implement, test and modify Increases modularity of design, but overhead in moving through many layers means it is less efficient than a monolithic OS problem with mapping functions to layers (ordering of layers)

Client/Server operating systems Client Application Network Server Memory Server Process Server Print Server File Server User Mode Microkernel Hardware Kernel Mode Send Reply

Client/Server operating systems operating system code is organised into a series of independent processes called servers each server provides a set of services to other parts of the operating system or to user programs via a defined interface of service requests requesting process (client) requests service by sending a message to server service usually involves messages being passed back from server to client

Client/Server operating systems (Cont.) microkernel is privileged operating system code that is responsible for acting as postmaster for messages passed between servers and clients servers are small and self-contained, hide details of their implementation, etc. - easy to change But, like layered OS there is an overhead produced by the need to communicate between clients and servers.

References Operating System Concepts. Chapter 2.