Download slides - network systems lab @ sfu

School of Computing Science
Simon Fraser University
CMPT 300: Operating Systems I
Ch 2: Operating System Structures
Dr. Mohamed Hefeeda
1
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
2
Operating System Services
OS provides two sets of services
One for user convenience
 Another for efficient use of resources
3
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
4
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
5
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
6
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, …
7
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)
8
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)
9
System Calls: Example
 System call sequence to copy contents of a file
to another
10
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
11
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)
12
API – System Call – OS Relationship
13
Example: Standard C Library
 C program invoking
printf() library call,
which calls write()
system call
14
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
15
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, ….
16
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
17
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
18
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
19
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
20
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
21
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
22
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
23
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
24
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
25
Modular Structure: Solaris
26
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)
27
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)
28
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
29
Example: VMware Architecture
30
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
31
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: ??
32
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?
33
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
34
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
35