TDDI04
Concurrent Programming,
Operating Systems,
and Real-time Operating Systems
Operating System Structures – Overview
§ Operating System Services
Operating System Structures
[SGG7] Chapter 2
Copyright Notice: The lecture notes are mainly based on Silberschatz’s, Galvin’s and Gagne’s book (“Operating System
Concepts”, 7th ed., Wiley, 2005). No part of the lecture notes may be reproduced in any form, due to the copyrights
reserved by Wiley. These lecture notes should only be used for internal teaching purposes at the Linköping University.
•
•
•
User – Operating System Interface
System Calls
System Programs
§ Operating System Structure
•
•
•
•
Layered Approach
Microkernels
Modules
Virtual Machines
§ Operating System Generation
Acknowledgment: The lecture notes are originally compiled by C. Kessler, IDA.
Klas Arvidsson, IDA,
Linköpings universitet.
§ System Boot
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Operating System Services
§ ... More functions that are helpful to the user:
•
§ Functions that are helpful to the user or user program:
User interface
or through message passing (packets moved by the OS)
> Graphics User Interface (GUI)
•
> Batch
•
•
Communications
Processes may exchange information,
on the same computer or between computers over a network
> Communications may be via shared memory
> Command-Line Interface
•
© Silberschatz, Galvin and Gagne 2005
Operating System Services (Cont.)
Provide functions for the user or for the system itself.
•
3.2
Error detection
> Errors may occur in the CPU and memory hardware,
in I/O devices, in user program
Program execution
load a program into memory, run it, terminate it.
> OS should take the appropriate action
I/O operations
A running program may require I/O to/from a file or an I/O device.
> Debugging facilities
to ensure correct and consistent computing
File-system manipulation
read and write files and directories, create and delete them,
search them, list file information, permission management.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.3
© Silberschatz, Galvin and Gagne 2005
Operating System Services (Cont.)
§ OS functions supporting the efficient operation of the system itself:
• Resource allocation – When multiple users or multiple jobs are
running concurrently, resources must be allocated to each of them
> Types of resources: CPU time, main memory, file storage, I/O dev.
• Accounting
> keep track of which users use how much and what kind of
resources
• Protection and security –
> In multiuser or networked computer system,
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
User Operating System Interface (1)
§ Command Line Interpreter (CLI)
allows direct command entry
•
Sometimes implemented in the kernel,
sometimes by a system program
•
•
Sometimes multiple flavors implemented – shells
Primarily fetches a command from user and executes it
> built-in commands or
– control use of stored information;
> just names of programs ( -> extendible)
– concurrent processes should not interfere with each other
> Protection: ensure that all access to system resources is controlled
3.4
•
Unix example (csh):
rm file.txt
> Security of the system from outsiders
– requires user authentication,
– defending external I/O devices from invalid access attempts
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.5
> A chain is only as strong as its weakest link.
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.6
© Silberschatz, Galvin and Gagne 2005
1
User Operating System Interface (2)
System Calls – Overview
§ Graphical User Interface (GUI): user-friendly desktop metaphor
§ System call mechanism
•
•
•
•
Icons represent files, programs, actions, etc
•
Invented at Xerox PARC
§ System call API
Folders represent directories
Menus (pulldown / popup) show available commands
Various mouse button clicks over objects in the interface
cause various actions (e.g., provide information, show options, execute
function, open directory)
§ Passing parameters
§ Types of system calls
§ Many systems now include both CLI and GUI interfaces
•
•
Microsoft Windows is GUI with CLI “command” shell
•
Solaris is CLI with optional GUI interfaces (CDE, Java Desktop, KDE)
Apple Mac OS X as “Aqua” GUI interface with UNIX kernel underneath
and shells available
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.7
© Silberschatz, Galvin and Gagne 2005
Recall: Dual-Mode Operation
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
3.8
Dual-Mode Operation (Cont.)
§ Sharing system resources requires the operating system to
ensure that an incorrect program cannot cause other
programs to execute incorrectly.
§ Hardware support (mode bit) to differentiate between at
least two modes of operations.
§ When an interrupt or fault occurs, hardware switches to
kernel mode.
§ System calls – call OS service
§ User mode
• Execution done on behalf of a user
• Access only to memory addresses owned by the process
Interrupt/fault
kernel
§ Kernel mode (also supervisor mode or system mode)
• Execution done on behalf of operating system.
user
set user mode
•
Privileged instructions
instructions that may be harmful,
e.g., system login, set priorities, system halt, etc.
•
Unrestricted memory access
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
© Silberschatz, Galvin and Gagne 2005
3.9
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.10
© Silberschatz, Galvin and Gagne 2005
Example of System Calls
System Call API
§ System call sequence to copy contents of one file to another
§ Programming interface to the services provided by the OS
§ Typically written in a high-level language (C or C++)
§ Mostly accessed by programs via a high-level Application
Program Interface (API) rather than direct system call use
§ Three most common APIs are
•
•
Win32 API for Windows,
•
Java API for the Java virtual machine (JVM)
POSIX API for POSIX-based systems
(including virtually all versions of UNIX, Linux, Mac OS X)
Remark: the system-call names used here and in the book are generic.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.11
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.12
© Silberschatz, Galvin and Gagne 2005
2
Example of a System Call API
System Call API Implementation
§ ReadFile() function in Win32 API (function for reading from a file)
§ System call implementation is hardware-specific,
e.g. special trap instruction with a system call number passed
in a register, indexing the interrupt vector (branch table)
§ System call interface (usually, in C) invokes the intended
system call in OS kernel and returns status of the system call
and any return values
§ Advantage:
§ Parameters passed to ReadFile():
• file — the file to be read
• buffer — a buffer where the data will be read into and written from
• bytesToRead — the number of bytes to be read into the buffer
• bytesRead — the number of bytes read during the last read
•
•
Caller does not need to know anything about how the
system call is implemented
•
Most details of OS interface hidden from programmer by
API
ovl — indicates if overlapped I/O is being used
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.13
© Silberschatz, Galvin and Gagne 2005
System Call API – OS Relationship
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.14
© Silberschatz, Galvin and Gagne 2005
Standard C Library Example
§ C program invoking printf(),
which calls write() system call
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.15
© Silberschatz, Galvin and Gagne 2005
System Call Parameter Passing
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.16
© Silberschatz, Galvin and Gagne 2005
System Call Parameter Passing via Block
§ Three general methods used to pass parameters to syscalls:
•
Simplest: pass the parameters in registers
•
Parameters stored in a block in memory, and address of
block passed as a parameter in a register
•
Parameters pushed onto the stack by the program and
popped off the stack by the operating system
> but number of parameter registers is limited
> This approach taken by Linux and Solaris
§ Block and stack methods do not limit the number or length of
parameters being passed
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.17
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.18
© Silberschatz, Galvin and Gagne 2005
3
Types of System Calls
Solaris 10 dtrace Following System Call
§ Process control
load, execute, end, abort, create, terminate, wait ...
memory allocation and deallocation
dtrace:
§ File management
open, close, create, delete, read, write, get/set attributes...
§ Device management
request / release device, read, write, ...
§ Information maintenance
get / set time, date, system data, process / file attributes
§ Communications
create / delete connection, send, receive, ...
dynamic tracing facility
instrument the code to
collect diagnostic
information during
runtime,
e.g. entry/exit of
functions
U = User mode
K = Kernel mode
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.19
© Silberschatz, Galvin and Gagne 2005
FreeBSD Running Multiple Programs
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.20
© Silberschatz, Galvin and Gagne 2005
System Programs
§ provide a convenient environment for program development and
execution.
For each new user, the kernel
starts a new shell process in
a fresh memory area with the
fork() system call.
•
•
•
•
•
•
For each program started, the
shell starts a new process in
a fresh memory area with the
fork() system call
File management
Status information
File modification
Programming language support: Compilers, assemblers, debuggers...
Program loading and execution
Communications: Message passing, e-mail, web browser, ...
§ Some of them are simply user interfaces to system calls;
others are considerably more complex
§ Most users’ view of the operation system is defined by system programs,
not the actual system calls
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.21
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.22
Operating System Design and Implementation
Operating System Structure
§ Design and implementation of OS:
No “silver bullet”, but some approaches have proven
successful
§ How to manage OS complexity?
§ Internal structure of different OS can vary widely
§ Start by defining goals and specifications
§ Affected by choice of hardware, type of system
§ User goals versus 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
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.23
© Silberschatz, Galvin and Gagne 2005
© Silberschatz, Galvin and Gagne 2005
§ Divide-and-conquer!
§ Decompose into smaller components
with well-defined interfaces and dependences
•
•
•
•
Layered Approach
Microkernels
Modules
Virtual Machines
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.24
© Silberschatz, Galvin and Gagne 2005
4
Simple Structure
Layered Approach
§ MS-DOS – written to provide the most functionality in the least
space
§ The operating system is
divided into a number of
layers (levels),
each built on top of lower layers.
•
Not divided into
modules
•
Although MS-DOS
has some structure,
its interfaces and levels
of functionality are
not well separated
•
The bottom layer (layer 0)
is the hardware
•
the highest (layer N)
is the user interface.
§ Modularity: Design layers
s.t. each uses functions
and services of only
lower-level layers.
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.25
© Silberschatz, Galvin and Gagne 2005
UNIX System Structure: 2 Layers
new
operations
..
.
existing
operations
..
.
layer M
hidden
operations
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.26
..
.
layer M – 1
© Silberschatz, Galvin and Gagne 2005
THE OS: 6 Layers
§ A layered design was first used in the THE operating system
[Dijkstra’68, Technische Hogeschool at Eindhoven, NL]
layer 5: user programs
layer 4: buffering for input and output
layer 3: operator-console device driver
layer 2: memory management
layer 1: CPU scheduling
layer 0: hardware
see SGG7 Ch. 23.4, p. 847
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.27
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.28
© Silberschatz, Galvin and Gagne 2005
Microkernel System Structure
Modules
§ “Lean kernel”: Moves as much service functionality as
possible from the kernel into “user” space
§ Most modern operating systems implement kernel modules
§ Component-based approach:
§ Communication takes place between user modules
using message passing
§ Example: Mach kernel, used e.g. in Tru64 Unix or Mac OS-X
§ Benefits:
•
•
•
•
Easier to extend a microkernel
Easier to port the operating system to new architectures
•
Performance overhead of user space to kernel space
communication
More reliable (less code is running in kernel mode)
More secure
§ Detriments:
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.29
© Silberschatz, Galvin and Gagne 2005
•
•
•
Each core component is separate
Each talks to the others over known interfaces
Each is loadable as needed within the kernel
§ Example: Solaris
loadable kernel modules
§ Overall, similar to layers
but more flexible
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.30
© Silberschatz, Galvin and Gagne 2005
5
Virtual Machines
Virtual Machines (Cont.)
§ A virtual machine provides an interface identical to the underlying bare
hardware.
•
Example: Multitasking OS creates the illusion that each process
executes on its own (virtual) processor with its own (virtual) memory.
§ A virtual machine takes the layered approach to its logical conclusion:
It treats hardware and the operating system kernel
as though they were all hardware.
§ Virtual machine implementation intercepts operations and interprets them.
§ The virtual machines share the resources of the physical computer:
•
•
•
CPU scheduling: create illusion that users have their own processor
Non-virtual Machine
Virtual disks with virtual file systems on physical disk / file system
Virtual Machine
A normal user time-sharing terminal serves as the virtual machine
operator’s console
§ Can run multiple and different OS’s on the same physical computer
•
Examples: VMware, Xen
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
(a) Nonvirtual machine
3.31
© Silberschatz, Galvin and Gagne 2005
Virtual Machines – Advantages, Drawbacks
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
(b) virtual machine
3.32
© Silberschatz, Galvin and Gagne 2005
3.34
© Silberschatz, Galvin and Gagne 2005
VMware Architecture
§ Complete protection of system resources
since each virtual machine is isolated from all other virtual machines.
• however, permits no direct sharing of resources.
§ Perfect vehicle for operating-systems research and development
(and teaching ;-).
• System development is done on the virtual machine,
instead of on a physical machine
and so does not disrupt normal system operation.
• Example: PINTOS, NACHOS
§ Portability across multiple platforms (host OS, hardware)
• Example: Java Virtual Machine (JVM)
• (Nowadays very popular also in computer architecture:
e.g., TransMeta Crusoe processor emulates IA-32 on VLIW)
§ Difficult to implement
• to provide an exact duplicate to the underlying machine
§ See also: IEEE Computer May 2005 special issue on Virtual Machines
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.33
© Silberschatz, Galvin and Gagne 2005
The Java Virtual Machine
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
Operating System Generation
§ Operating systems are designed to run on any of a class of
machines ...
•
but the system must be configured for each specific
computer site:
CPU type, memory sizes, devices, performance
parameters (e.g. scheduling algorithm), ...
§ SYSGEN program obtains information concerning the specific
configuration of the hardware system
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.35
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.36
© Silberschatz, Galvin and Gagne 2005
6
Booting
Operating System Structures – Summary
§ Booting = starting up a computer by loading the kernel
§ Operating System Services
§ Bootstrap loader: The initial program executed when
system is powered up
•
•
code stored in ROM at address where execution starts
•
initializes the system
locates the kernel, loads it into memory, and start its
execution
> CPU registers, device controllers, memory contents ...
§ Once the OS is loaded, the OS starts executing the first
process (e.g., init) and then waits for some event to occur
(interrupt).
•
•
•
User – Operating System Interface
System Calls
System Programs
§ Operating System Structure
•
•
•
•
Layered Approach
Microkernels
Modules
Virtual Machines
§ Operating System Generation
§ System Boot
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.37
© Silberschatz, Galvin and Gagne 2005
TDDI04, K. Arvidsson, IDA, Linköpings universitet.
3.38
© Silberschatz, Galvin and Gagne 2005
7