1. CMPT 300: Operating Systems I
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 File management
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: , 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?
In some of your projects, you will
Modify the Linux kernel and compile on a Linux machine and test on another machine with different configurations (the VM running on WinXP)
Configurations are defined in .config file

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