School of Computing Science Simon Fraser University CMPT 300: Operating Systems I

1. School of Computing Science Simon Fraser University CMPT 300: Operating Systems I Ch 2: Operating System Structures Dr. Mohamed Hefeeda

2. Objectives • Describe services provided by OS to users, processes, and other systems • Discuss various ways of structuring OS • Explain customization of OS for different machines and how OS boots

3. Operating System Services • OS provides two sets of services • One for user convenience • Another for efficient use of resources

4. OS Services: User Convenience • User interface • Command-Line Interface (CLI) or Graphics User Interface (GUI) • Program execution • load program into memory and run it • end execution, either normally or abnormally • I/O operations • programs may require I/O, which may involve a file or an I/O device • File-system manipulation • programs may need to do the following on files/directories … • read, write • create, delete • search, list file Information • permission management

5. OS Services: User Convenience (cont’d) • Communications • Processes may exchange information, on the same computer or between computers over a network • Error detection • OS needs to be constantly aware of possible errors • May occur in 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

6. OS Services: Efficient Use of Resources • Resource allocation • When multiple users or multiple jobs running concurrently, resources must be allocated to each of them • Accounting • To keep track of which users use how much and what kinds of computer resources • Protection and security • OS should provide secure and protected access to data • Protection: involves ensuring that all access to system resources is controlled • Security: of the system from outsiders requires user authentication

7. User-OS Interface: CLI • CLI allows direct command entry • Implemented in kernel or as a systems program • Called shell • Multiple flavors (shells) may exist • Function: get a command from user and execute it • Command could be: built-in or user programs • Example shells: • bash, csh, tcsh, …

8. User-OS Interface: GUI • User-friendly desktop metaphor interface • Usually mouse, keyboard, and monitor • Icons represent files, programs, actions, etc • Various mouse buttons over objects in the interface cause various actions (provide information, options, execute function, open directory (known as a folder) • Invented at Xerox PARC • Many systems now include both CLI and GUI • Microsoft Windows is GUI with CLI “command” shell • Apple Mac OS X has “Aqua” GUI interface with UNIX kernel underneath and shells available • Solaris is CLI with optional GUI interfaces (Java Desktop, KDE)

9. System Calls • How can we access OS services? • System calls • A programming interface to OS services • Typically written in high-level language (C or C++) • Mostly accessed by programs via a high-level Application Program Interface (API), rather than direct system call • Why use APIs rather than direct system calls? • Portability • Ease • Three most common APIs • Win32 API for Windows • POSIX API for POSIX-based systems (UNIX, Linux, and Mac OS X) • Java API for the Java virtual machine (JVM)

10. System Calls: Example • System call sequence to copy contents of a file to another

11. Example: strace on Linux • Try the following commands on a Linux machine: • $ strace -c ls • Displays summary info on system calls invoked during the execution of the command ‘ls’ • $ strace –o trace.out ls • Details of the invoked system calls during the execution of the command ‘ls’ are saved in the file ‘trace.out’ • $ man strace • Displays info (manual) on strace

12. System Call Implementation • Typically • A number is associated with each system call • System call interface maintains table indexed based on these numbers • System call interface invokes intended system call in OS kernel and returns status of system call and any return values • The caller need know nothing about how the system call is implemented • Just need to obey API and understand what OS will do as a result call • Most details of OS interface hidden from programmer by API • Managed by run-time support library (set of functions built into libraries included with compiler)

13. API – System Call – OS Relationship

14. Example: Standard C Library • C program invoking printf() library call, which calls write() system call

15. 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 methods to pass parameters to 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 OS • Note: Block and stack methods do not limit the number or length of parameters being passed

16. Types of System Calls • Process control • Create, load, execute, abort, … • File management • Open, close, read, write, delete, … • Device management • Read, write, request, release, … • Information maintenance • Get time/date, get process attributes, … • Communications • Send, receive, create communication channel, ….

17. System Programs • System programs provide a convenient environment for program development/execution • Most users’ view of OS is defined by system programs, not the actual system calls • Examples: • File management: create, copy, delete, list, … • File modification: text editors, search, … • Status info: disk space, memory usage, CPU utilization, • Try: $top, $ps, $du, $df, $who • Programming language support: compilers, debuggers, … • Check out $man gdb (Gnu Debugger) • Communications: email, web browser, remote log in, .. • Check out: $pine • Application programs: database engine, spread sheet

18. OS Design and Implementation • Internal structure of different OS can vary widely • Affected by choice of hardware, type of system • Guideline: • Start by defining goals and specifications • User goals vs. System goals • User goals – OS should be convenient to use, easy to learn, reliable, safe, and fast • System goals – OS should be easy to design, implement, and maintain, as well as flexible, reliable, error-free, and efficient

19. OS Design and Implementation (cont’d) • Important principle:Separate Policy from Mechanism • What is policy and what is mechanism? • Policy decides what will be done • Mechanism determines how to do it • Why separation? • Allows maximum flexibility if policy decisions are to be changed later • Example • Policy: CPU-intensive programs get higher priority over I/O-intensive ones • Mechanism: implement a priority system with different levels

20. Operating System Structure • How would you structure a complex system like OS? • Simple • monolithic (one layer) or some layering but no clear interfaces • Layered • Microkernel • Modular • Virtual Machines

21. Simple Structure: Old UNIX • Monolithic structure: two parts • Systems programs • Kernel: everything below system-call interface and above hardware • File system, CPU scheduling, memory management, …. • Difficult to implement and maintain: Too much in one layer

22. Simple Structure: MS-DOS • MS-DOS – written to provide the most functionality in the least space • Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated • No protection • Apps crash whole system • Limited by hardware at that time

23. Layered Structure • OS is divided into layers • Each layer uses services of only lower-level layers • Easy to develop, debug, and update: Focus on one layer at a time • Problems with layering? • Less efficient: every layer adds some overhead • Tricky to define layers • Ex: two layers that need each other’s services • CPU scheduler and backing-store driver

24. Microkernel Structure • Kernel provides minimal services: • Process and memory management, and communication facility • Rest of services are moved to user space • Communication takes place between user modules using message passing (through the kernel) • Benefits: • Easier to extend microkernel • Easier to port the operating system to new architectures • More reliable and secure • Less code is running in kernel mode, most are user mode ==> service fails, the rest of OS is untouched • Disadvantages: • Performance overhead: communication among user modules and the kernel

25. Modular Structure • Implement OS as separate components (modules) • Each module has a well-defined interface • Modules talk to each other using interfaces • Modules are loaded within the kernel when needed • Most modern OSes (e.g., Solaris, Linux) implement kernel modules

26. Modular Structure: Solaris

27. Modular Structure: Advantages? • Similar to layers but more flexible • Avoids the problem of defining layers • Easy to maintain, update, and debug: focus on one module at a time • Efficient: modules can call each others directly (no layers in between and no message passing)

28. Hybrid Structure: Mac OS X • Layered approach with one layer as a microkernel • Mach provides: memory management, RPC, IPC, scheduling • BSD provides: file system, CLI, networking, APIs • Allows for kernel extensions (loadable modules)

29. Virtual Machines • Virtual machine abstracts hardware of a single computer into several different execution environments (OSes) • Resources are shared to create virtual machines • CPU scheduling and virtual-memory techniques help to create the illusion that users have their own processors and memory • Examples • VMware • Java Virtual Machine

30. Example: VMware Architecture

31. Virtual Machines (cont’d) • Why VMs? • OS research and development • Test OS on VMs with various configurations • Safer, faster, and cost-effective to test on VMs • VMs provide complete protection of system resources • Each virtual machine is isolated from all others

32. Operating System Configuration • Do we develop OSes on machines that run them? • NO! Usually develop on a machine and run on another • Think of OS for cell phones or slow/small computers • How would we customize OS for a target machine? • Get information about target machine • e.g., CPU, memory, hard drive, I/O devices attached • Save this info in configuration files • THEN: ??

33. Operating System Configuration (cont’d) • Recompile OS code with configuration files • Tailor OS precisely for target machine • Efficient OS, but not flexible and recompilation takes time; OR • Load or link modules based on configuration files • Modules (e.g., device drivers) are precompiled • Fast configuration, produce fairly general systems  less efficient; OR • Select during run time • Kernel contains code for all supported configurations • Selection occurs at execution time • flexible, but large kernel • When would you use each of these methods?

34. System Boot • OS must be available to hardware to start it • When computer is powered up, the instruction register is loaded with a predefined memory location • Typically, the address of the bootstrap loader in ROM • Bootstrap loader routine • Performs diagnostic tests (Power-on Self Testing) • Loads a small piece of code from a fixed location (block 0) on the disk into memory, which • loads the rest of the loader from disk, which • loads kernel itself • Examples: • LiLo (Linux Loader) and Grub

35. Summary • OS provides two sets of services for • user convenience and • efficient use of resources • OS-user interface: CLI (shells) or GUI (windows) • System calls: interface to OS services • Typically used through APIs for portability and ease • OS design: specify requirements, separate policies from mechanisms • OS structure: simple, layered, microkernel, modular, VM • OS configuration and boot