Structure of Operating System

1. Structure of Operating System

2. Operating System Concepts • The most important concepts related to OS are given as under: • Process • Files • The Shell • System Call

3. Operating System Concepts Process: • Process is the program in execution. • The entity that can be assigned to and executed on a processor • It consisted of the executable program, the program’s data, and Stack, program counter, stack pointer and other registers. • All these information are stored in the process table.

4. Operating System Concepts Files: • Files consists of sequence of bit, byte, lines or records whose meanings are defined by its creator. • Files are mapped by the OS on to the physical devices.

5. Operating System Concepts • Following major tasks are performed by OS. • The creation and deletion of files. • The support of primitives for manipulating files and dir. • Mapping files onto secondary storage. • The backup of files on stable storage media.

6. OS Concepts The Shell: • Editors, compilers, assemblers, linkers and command interpreters are not the part of OS. • UNIX command interpreter is called The Shell. • Shell make heavy use of many OS features. • It is interface between a user and the OS. • When any user log in, a shell is started up. • The Shell has terminal as standard input and standard output.

7. OS Kernel • The AUI is glued to the OS Kernel via the language libraries and the system call interface • The language libraries and the system call interface comprise Application Programmer’s Interface (API) • The system call interface layer contains entry point in the kernel code • Any user or application request that involves access to any system resource must be handled by the kernel code

8. OS Kernel Real work is done in the kernel Users Applications Operating System API, AUI Operating System Kernel Computer Hardware

9. Entry Points into Kernel System Call Signal Interrupt Trap

10. OS Kernel • Kernel consists of everything below the System Call interface and above the physical h/w. • The AUI is glued to the OS Kernel via the language libraries and the system call interface • The language libraries and the system call interface comprise Application Programmer’s Interface (API) • The system call interface layer contains entry point in the kernel code • Any user or application request that involves access to any system resource must be handled by the kernel code

11. OS Kernel • The kernel contains the code to perform the following functions: • Interrupt Handling • Process creation and destruction • Process state switching • Dispatching • Process suspension and resumption • Process synchronization • Inter Process Communication (IPC) • Manipulation of PCB • Memory management • Support for file system etc.

12. OS Concepts System Calls: Userprocesses must not be given open access to the kernel code • Any user/application request that involves access to any system resource must be handled by the kernel code. • System call is a mechanism used by an application program to request a service from Operating System. • System Callis a layer of s/w at the top of kernel that allows you to go inside the kernel code. • A System callis usually a request to the OS kernel to do a HW, system specific or privileged operation.

13. OS Concepts System Calls: Step 1: A user program makes a call to a library function. • Corresponding to each System Call is a Library Call. Step 2: Library routine puts appropriate parameters at a well-known place (registers, stack, or a table in memory). Step 3: The TRAP Instruction is executed to change mode from user to kernel. Step 4: Control goes to operating system.

14. OS Concepts System Call Process Library Call System Call trap Dispatch Table Service Code Kernel Code Dispatch Table

15. OS Concepts System Calls Step 5: OS determines which system call is to be carried and examines the parameters. Step 6: Kernel indexes the dispatch table, whichcontains pointers to service routines for system calls. Step 7: Service routine is executed. • If the parameters are valid, OS performs tasks and final result is sent back to user process. Otherwise it return error and that error report is also sent back to process. Step 8: Control is given back to the user program. Step 9: Library function executes the instruction following the trap.

16. OS Concepts API– System Call – OS Relationship

17. OS Concepts Standard C Library Example • C program invoking printf() library call, which calls write() system call

18. OS Concepts System Call Parameter Passing • Three general methods used to pass parameters to the OS • Simplest: pass the parameters in 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

19. OS Concepts Parameter Passing via Table

20. OS Concepts Types Of System Calls • Process Control • File Management • Device Management • Information maintenance • Communications

21. OS Concepts Types Of System Calls • Process Control • end, abort • load, execute • create process, terminate process • get process attributes, set process attributes • File Management • create file, delete file • open, close • read, write, reposition • Get file attributes, set file attributes, execute

22. OS Concepts Types Of System Calls • Device Management • request device, release device • read, write, reposition • get device attributes, set device attributes • Information maintenance • get process, file or device attributes • set process, file or device attributes • Communications • create, delete communication connection • send, receive messages

23. OS Components • Process management • Main memory management • Secondary storage management • I/O system management • File management • Protection system • Networking • Command-line interpreter (shells)

24. Operating System Design and Implementation • Start by defining goals and specifications • 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 • Mechanism: determine how to do something • Policy: determine what will be done • Separation of mechanism and policy is important for flexibility. • Mechanism is implemented and policy is maintained by the administrator. • Ex: CPU time per process.

25. Operating System Design and Implementation • Implementation in: • Assembly language • Higher level languages: • Easier to code • Compact code • Easier to port

26. Operating System Structures • OS is a complex system and must be structured carefully. • A common approach is to partition the system into small components with each component performing a well-defined task. • Following structures are used for OS: • Simple Structure • Layered Approach • Microkernels • Modules • Virtual Machines

27. Simple Structures … • Monolithic Systems: • The structure is that there is no structure. • The OS is written as a collection of procedures. • Each procedure can call other procedure whenever it needs. • There is no information hiding; every procedure is visible to every other procedure • In this approach all the individual procedures are complied together into single object file with the linker. • Even in monolithic systems, however, it is possible to have at least a little structure. The system calls provided by the OS are requested by putting the parameters in well-defined places, such as in registers or on the stack, and then executing a special trap instruction.

28. Simple Structures MS-DOS : written to provide the most functionality in the least space, so it was not divided into modules carefully

29. Simple Structures … • UNIX consists of two separable parts, the kernel and the system programs. • Every thing below the system call interface and above the physical hardware is the kernel. • An enormous amount of functionality combined in one level, UNIX is difficult to enhance as changes in one section could adversely affect other areas.

30. UNIX System Structure

31. Layered Approach • The OS is broken up into a number of layers • Bottom layer is hardware and the topmost layer (layer N) is the user interface • A typical layer consists of data structures and a set of routines to service the layer above it • THE operating system by Dijkstra • IBM’s OS/2

32. Layered Approach …

33. Layered Approach … • Modularity • Each layer uses functions and services of only lower layers • Simplifies debugging and system verification. • The major difficulty with layered approach is careful definition of layers, because a layer can only use the layers below it • Less efficient than other approaches; e.g. when a program executes an I/O operation, it executes a system call that is trapped to the I/O layer, which in turn call the memory mgmt layer, which in turn call the CPU scheduling layer which is then passed to h/w. At each layer parameters may be modified, data may need to be passed and so on

34. Microkernel • Structures the operating system by removing all non-essential components from the kernel and implementing them as system and user level programs • Smaller kernel • Only few essential services / functions are assigned to the kernel; e.g. address space checking, IPC and basic scheduling. Other OS services (file service, memory service, terminal service, process service) are given to servers that run in user mode and are treated like any other application by the microkernel • Main function is to provide a communication facility between client programs and the various services that are also running in the user space.

35. Microkernel … Windows NT Client-Server Structure To request a service, such as reading a block of a file, a user process / client process sends a request to a server process, which then does the work and sends back the answer. Kernel dose all the communication.

36. Microkernel … Advantages • Easier to extend the OS—new services are added to user space and consequently do not require modification of the kernel and/or its recompilation • Easier to maintain operating system code (enhancement, debugging, etc.) • OS is easier to port from one hardware to another • Fault Isolation. Since all the servers run as user-mode processes, and not in kernel mode, they do not have direct access to the h/w. As a consequence, if a bug in the File Server is triggered, the file service may crash, but this will not usually bring the whole system down • More security and reliability • Disadvantages • Performance decreases due to extensive message passing (IPC) • Mach, MacOS X Server, QNX, OS/2, and Windows NT

37. Modules • Most modern operating systems implement modules using object-oriented approach. • The kernel has a set of core components and dynamically links in additional services. • Each module talks to others over known interfaces. • It resembles layered system; but it is more flexible in that any module can call any other module. • It is also like microkernel in that primary module has only core functions but is more efficient because modules don’t need to invoke message passing in order to communicate.

38. Virtual Machines • Abstract the hardware of a single computer into several different execution environments, thereby creating an illusion that each separate execution environment is running its own computer. • On a time-sharing system with virtual machine support, users may be working on different operating systems

39. Virtual Machines … Virtual Machine OS Conventional Multiprogrammed OS VM 1 VM 2 . . . VM n Job 2 . . . . Job n Job 1 In virtual multiprogramming system, a single real machine gives an illusion of several virtual machines, each having its own virtual processor, storage and I/O devices. In conventional multiprogramming processes are allocated a portion of the real machine resources. The same machine resources are distributed among several processes.

40. Virtual Machines … Non Virtual Machine Virtual Machine

41. VirtualMachines (cont…)

42. Virtual Machines … • System development done without disrupting normal system operation. Provides complete protection of system resources, since VM is isolated from all other VMs. • A perfect vehicle for OS research and development. • Difficult to implement.