CS194-24
Advanced Operating Systems
Structures and Implementation
Lecture 4
OS Structure (Con’t)
Modern Architecture
February 6th, 2013
Prof. John Kubiatowicz
http://inst.eecs.berkeley.edu/~cs194-24
Goals for Today
• OS Structure (Con’t): The Linux Kernel
• Modern Computer Architecture
Interactive is important!
Ask Questions!
Note: Some slides and/or pictures in the following are
adapted from slides ©2013
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.2
Recall: OS Resources – at the center of it all!
• What do modern OSs do?
– Why all of these pieces running
together?
– Is this complexity necessary?
Independent
Requesters
• Control of Resources
– Access/No Access/
Partial Access
» Check every access to see if it
is allowed
– Resource Multiplexing
» When multiple valid requests
occur at same time – how to
multiplex access?
» What fraction of resource can
requester get?
Access Control and Multiplexing
– Performance Isolation
» Can requests from one entity
prevent requests from another?
• What or Who is a requester???
– Process? User? Public Key?
– Think of this as a “Principle”
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.3
Recall: Microkernel Structure
Figure ©Wikipedia
Monolithic
Kernel
Microkernel
• Moves as much from the kernel into “user” space
– Small core OS running at kernel level
– OS Services built from many independent user-level processes
– Communication between modules with message passing
• Benefits:
–
–
–
–
–
Easier to extend a microkernel
Easier to port OS to new architectures
More reliable (less code is running in kernel mode)
Fault Isolation (parts of kernel protected from other parts)
More secure
• Detriments:
– Performance overhead severe for naïve implementation
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.4
Recall: Modules-based Structure
• Most modern operating systems implement modules
–
–
–
–
Uses
Each
Each
Each
object-oriented approach
core component is separate
talks to the others over known interfaces
is loadable as needed within the kernel
• Overall, similar to layers but with more flexible
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.5
Recall: ExoKernel
• Provide extremely thin layer to present hardware
resources directly to users
– As little abstraction as possible
– Only Protection and Multiplexing of resources
• On top of Exokernel is the LibraryOS which provides
much of the traditional functionality of OS in Library
• Low-level abstraction layer
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.6
Concurrency
• “Thread” of execution
– Independent Fetch/Decode/Execute loop
– Operating in some Address space
• Uniprogramming: one thread at a time
–
–
–
–
MS/DOS, early Macintosh, Batch processing
Easier for operating system builder
Get rid concurrency by defining it away
Does this make sense for personal computers?
• Multiprogramming: more than one thread at a time
– Multics, UNIX/Linux, OS/2, Windows NT/2000/XP,
Mac OS X
– Often called “multitasking”, but multitasking has
other meanings (talk about this later)
• ManyCore  Multiprogramming, right?
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.7
The Basic Problem of Concurrency
• The basic problem of concurrency involves resources:
– Hardware: single CPU, single DRAM, single I/O devices
– Multiprogramming API: users think they have exclusive
access to shared resources
• OS Has to coordinate all activity
– Multiple users, I/O interrupts, …
– How can it keep all these things straight?
• Basic Idea: Use Virtual Machine abstraction
– Decompose hard problem into simpler ones
– Abstract the notion of an executing program
– Then, worry about multiplexing these abstract machines
• Dijkstra did this for the “THE system”
– Few thousand lines vs 1 million lines in OS 360 (1K bugs)
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.8
Recall (61C): What happens during execution?
R0
…
R31
F0
…
F30
PC
Addr 232-1
Fetch
Exec
• Execution sequence:
–
–
–
–
–
–
2/6/13
Fetch Instruction at PC
Decode
Execute (possibly using registers)
Write results to registers/mem
PC = Next Instruction(PC)
Repeat
…
Data1
Data0
Inst237
Inst236
…
Inst5
Inst4
Inst3
Inst2
Inst1
Inst0
Kubiatowicz CS194-24 ©UCB Fall 2013
PC
PC
PC
PC
Addr 0
Lec 4.9
How can we give the illusion of multiple processors?
CPU1
CPU2
CPU3
CPU1
Shared Memory
CPU2
CPU3
CPU1
CPU2
Time
• Assume a single processor. How do we provide the
illusion of multiple processors?
– Multiplex in time!
• Each virtual “CPU” needs a structure to hold:
– Program Counter (PC), Stack Pointer (SP)
– Registers (Integer, Floating point, others…?)
• How switch from one CPU to the next?
– Save PC, SP, and registers in current state block
– Load PC, SP, and registers from new state block
• What triggers switch?
– Timer, voluntary yield, I/O, other things
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.10
Properties of this simple multiprogramming technique
• All virtual CPUs share same non-CPU resources
– I/O devices the same
– Memory the same
• Consequence of sharing:
– Each thread can access the data of every other
thread (good for sharing, bad for protection)
– Threads can share instructions
(good for sharing, bad for protection)
– Can threads overwrite OS functions?
• This (unprotected) model common in:
– Embedded applications
– Windows 3.1/Machintosh (switch only with yield)
– Windows 95—ME? (switch with both yield and timer)
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.11
What needs to be saved in Modern X86?
64-bit Register Set
Traditional 32-bit subset
EFLAGS Register
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.12
Modern Technique: SMT/Hyperthreading
• Hardware technique
– Exploit natural properties
of superscalar processors
to provide illusion of
multiple processors
– Higher utilization of
processor resources
• Can schedule each thread
as if were separate CPU
– However, not linear
speedup!
– If have multiprocessor,
should schedule each
processor first
• Original technique called “Simultaneous Multithreading”
– See http://www.cs.washington.edu/research/smt/
– Alpha, SPARC, Pentium 4 (“Hyperthreading”), Power 5
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.13
Chip-scale features of SandyBridge
• Significant pieces:
– Four OOO cores with Hyperthreads
–
–
–
–
» New Advanced Vector eXtensions (256-bit
FP)
» AES instructions
» Instructions to help with Galois-Field mult
» 4 -ops/cycle
Integrated GPU
System Agent (Memory and Fast I/O)
Shared L3 cache divided in 4 banks
On-chip Ring bus network
» Both coherent and non-coherent transactions
» High-BW access to L3 Cache
• Integrated I/O
– Integrated memory controller (IMC)
» Two independent channels of DDR3 DRAM
– High-speed PCI-Express (for Graphics cards)
– DMI Connection to SouthBridge (PCH)
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.14
How to protect threads from one another?
•
Need three important things:
1. Protection of memory
» Every task does not have access to all memory
2. Protection of I/O devices
» Every task does not have access to every device
3. Protection of Access to Processor:
Preemptive switching from task to task
» Use of timer
» Must not be possible to disable timer from
usercode
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.15
Recall: Program’s Address Space
– For a 32-bit processor there are
232 = 4 billion addresses
• What happens when you read or
write to an address?
–
–
–
–
Perhaps
Perhaps
Perhaps
Perhaps
Nothing
acts like regular memory
ignores writes
causes I/O operation
Program Address Space
• Address space  the set of
accessible addresses + state
associated with them:
» (Memory-mapped I/O)
– Perhaps causes exception (fault)
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.16
Providing Illusion of Separate Address Space:
Load new Translation Map on Switch
Data 2
Code
Data
Heap
Stack
Code
Data
Heap
Stack
Stack 1
Heap 1
Code 1
Stack 2
Prog 1
Virtual
Address
Space 1
Prog 2
Virtual
Address
Space 2
Data 1
Heap 2
Code 2
OS code
Translation Map 1
OS data
Translation Map 2
OS heap &
Stacks
Physical Address Space
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.17
X86 Memory model with segmentation
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.18
The Six x86 Segment Registers
• CS - Code Segment
• SS - Stack Segment
– “Stack segments are data segments which must be
read/write segments. Loading the SS register with a
segment selector for a nonwritable data segment
generates a general-protection exception (#GP)”
• DS - Data Segment
• ES/FS/GS - Extra (usually data) segment registers
– FS and GS used for thread-local storage/by glibc
• The “hidden part” is like a cache so that segment
descriptor info doesn’t have to be looked up each
time.
19
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.19
UNIX Process
• Process: Operating system abstraction to
represent what is needed to run a single program
– Originally: a single, sequential stream of execution
in its own address space
– Modern Process: multiple threads in same address
space!
• Two parts:
– Sequential Program Execution Streams
» Code executed as one or more sequential stream of
execution (threads)
» Each thread includes its own state of CPU registers
» Threads either multiplexed in software (OS) or
hardware (simultaneous multithrading/hyperthreading)
– Protected Resources:
» Main Memory State (contents of Address Space)
» I/O state (i.e. file descriptors)
• This is a virtual machine abstraction
– Some might say that the only point of an OS is to
support a clean Process abstraction
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.20
How do we multiplex processes?
• The current state of process held in a
process control block (PCB):
– This is a “snapshot” of the execution and
protection environment
– Only one PCB active at a time
• Give out CPU time to different
processes (Scheduling):
– Only one process “running” at a time
– Give more time to important processes
• Give pieces of resources to different
processes (Protection):
– Controlled access to non-CPU resources
– Sample mechanisms:
» Memory Mapping: Give each process their
own address space
» Kernel/User duality: Arbitrary
multiplexing of I/O through system calls
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Process
Control
Block
Lec 4.21
Modern “Lightweight” Process with Threads
• Thread: a sequential execution stream within process
(Sometimes called a “Lightweight process”)
– Process still contains a single Address Space
– No protection between threads
• Multithreading: a single program made up of a
number of different concurrent activities
– Sometimes called multitasking, as in Ada…
• Why separate the concept of a thread from that of
a process?
– Discuss the “thread” part of a process (concurrency)
– Separate from the “address space” (Protection)
– Heavyweight Process  Process with one thread
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.22
Single and Multithreaded Processes
• Threads encapsulate concurrency: “Active” component
• Address spaces encapsulate protection: “Passive” part
– Keeps buggy program from trashing the system
• Why have multiple threads per address space?
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.23
Preview: System-Level Control of x86
• Full support for Process
Abstraction involves a lot
of system-level state
– This is state that can
only be accessed in
kernel mode!
– We will be talking about
a number of these
pieces as we go through
the term…
• There is a tradeoff
between amount of
system state and cost of
switching from thread to
thread!
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.24
Additional system state for I/O
• Platform Controller Hub
– Used to be
“SouthBridge,” but no
“NorthBridge” now
– Connected to processor
with proprietary bus
» Direct Media
Interface
– Code name “Cougar
Point” for SandyBridge
processors
• Types of I/O on PCH:
SandyBridge
System Configuration
2/6/13
–
–
–
–
–
USB
Ethernet
Audio
BIOS support
More PCI Express (lower
speed than on Processor)
– Sata (for Disks)
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.25
Linux Structure
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.26
Layout of Linux Sources
•
Layout of basic linux sources:
kubitron@kubi(16)% ls
arch/
drivers/
block/
firmware/
COPYING
fs/
CREDITS
include/
crypto/
init/
Documentation/ ipc/
kubitron@kubi(17)%
Kbuild
kernel/
lib/
MAINTAINERS
Makefile
mm/
modules.builtin
modules.order
Module.symvers
net/
README
REPORTING-BUGS
samples/
scripts/
security/
sound/
System.map
tools/
usr/
virt/
vmlinux*
vmlinux.o
• Specific Directories:
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
2/6/13
arch:
block:
crypto:
Documentation:
drivers:
firmware:
fs:
include:
init:
ipc:
kernel:
lib:
mm:
net:
samples:
scripts:
security:
sound:
usr:
tools:
virt:
Architecture-specific source
Block I/O layer
Crypto API
Kernel source Documentation
Device drivers
Device firmware needed to use certain drivers
The VFS and individual filesystems
Kernel headers
Kernel boot and initialization
Interprocess Communication code
Core subsystems, such as the scheduler
Helper routines
Memory management subsystem and the vm
Networking subsystem
Sample, demonstrative code
Scripts used to build the kernel
Linux Security Module
Sound subsystem
Early user-space code (called initramfs)
Tools helpful for developing Linux
Virtualization infrastructure
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.27
System Calls
• Challenge: Interaction Despite Isolation
– How to isolate processes and their resources…
» While still permitting them to request help from the kernel
» Letting them interact with resources while maintaining usage policies such as
security, QoS, etc
– Letting processes interact with one another in a controlled way
» Through messages, shared memory, etc
• Enter the System Call interface
– Layer between the hardware and user-space processes
– Programming interface to the services provided by the OS
• Mostly accessed by programs via a high-level Application Program
Interface (API) rather than directly
– Get at system calls by linking with libraries in glibc
Call to
printf()
Printf() in the
C library
Write()
system call
• Three most common APIs are:
– Win32 API for Windows
– POSIX API for POSIX-based systems (including virtually all versions of UNIX,
Linux, and Mac OS X)
– Java API for the Java virtual machine (JVM)
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.28
Example of System Call usage
• System call sequence to copy the contents of one
file to another file:
• Many crossings of the User/Kernel boundary!
– The cost of traversing this boundary can be high
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.29
Example: Use strace to trace syscalls
•
prompt% strace wc production.log
execve("/usr/bin/wc", ["wc", "production.log"], [/* 52 vars */]) = 0
brk(0)
= 0x1987000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8f7000
access("/etc/ld.so.preload", R_OK)
= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)
= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=137151, ...}) = 0
mmap(NULL, 137151, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff24b8d5000
close(3)
= 0
open("/lib64/libc.so.6", O_RDONLY)
= 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\355\241,0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1922112, ...}) = 0
mmap(0x302ca00000, 3745960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x302ca00000
mprotect(0x302cb89000, 2097152, PROT_NONE) = 0
mmap(0x302cd89000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x189000) = 0x302cd89000
mmap(0x302cd8e000, 18600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x302cd8e000
close(3)
= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8d4000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8d3000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8d2000
arch_prctl(ARCH_SET_FS, 0x7ff24b8d3700) = 0
mprotect(0x302cd89000, 16384, PROT_READ) = 0
mprotect(0x302c81f000, 4096, PROT_READ) = 0
munmap(0x7ff24b8d5000, 137151)
= 0
brk(0)
= 0x1987000
brk(0x19a8000)
= 0x19a8000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99158576, ...}) = 0
mmap(NULL, 99158576, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff245a41000
close(3)
= 0
stat("production.log", {st_mode=S_IFREG|0644, st_size=526550, ...}) = 0
open("production.log", O_RDONLY)
= 3
read(3, "# Logfile created on Fri Dec 28 "..., 16384) = 16384
open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=26060, ...}) = 0
mmap(NULL, 26060, PROT_READ, MAP_SHARED, 4, 0) = 0x7ff24b8f0000
close(4)
= 0
read(3, "m: cannot remove `/tmp/fixrepo/g"..., 16384) = 16384
read(3, "a36de93203e0b4972c1a3c81904e': P"..., 16384) = 16384
read(3, "xrepo/git-tess/gitolite-admin/.g"..., 16384) = 16384
Many repetitions of these reads
2/6/13
read(3, "ixrepo/git-tess/gitolite-admin\n "..., 16384) = 16384
read(3, "ite/redmine/vendor/plugins/redmi"..., 16384) = 16384
read(3, "ited with positive recursionChec"..., 16384) = 16384
read(3, "ting changes to gitolite-admin r"..., 16384) = 2262
read(3, "", 16384)
= 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff24b8ef000
write(1, " 4704 28993 526550 production."..., 36 4704 28993 526550 production.log) = 36
close(3)
= 0
close(1)
= 0
munmap(0x7ff24b8ef000, 4096)
= 0
close(2)
= 0
exit_group(0)
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.30
Example of Standard API
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.31
System Call Implementation
• Typically, a number associated with each system call
– System-call interface maintains a table indexed according to these
numbers
– The fact that the call is by “number”, is essential for security reasons!
• The system call interface invokes intended system call in OS kernel
and returns status of the system call and any return values
– Return value: often a long (integer)
» Return of zero is usually a sign of success, but not always
» Return of -1 is almost always reflects an error
– On error – return code placed into global “errno” variable
» Can translate into human-readable errors with the “perror()” call
• The caller need know nothing about how the system call is
implemented
– Just needs 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)
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.32
API – System Call – OS Relationship
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.33
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 general methods used to pass parameters to the 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 the operating system
– Block and stack methods do not limit the number or length of
parameters being passed
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.34
Parameter Passing via Table
• Kernel must always verify parameters passed to
it by the user
– Are parameters in a reasonable range?
– Are memory addresses actually owned by the
calling user (rather than bogus addresses)
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.35
Types of System Calls
• Process control
–
–
–
–
–
–
–
end, abort
load, execute
create process, terminate process
get process attributes, set process attributes
wait for time
wait event, signal event
allocate and free memory
– Dump memory if error
– Debugger for determining bugs, single step
execution
– Locks for managing access to shared data between
processes
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.36
Types of System Calls
• File management
–
–
–
–
create file, delete file
open, close file
read, write, reposition
get and set file attributes
• Device management
–
–
–
–
2/6/13
request device, release device
read, write, reposition
get device attributes, set device attributes
logically attach or detach devices
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.37
Types of System Calls (Cont.)
• Information maintenance
– get time or date, set time or date
– get system data, set system data
– get and set process, file, or device attributes
• Communications
– create, delete communication connection
– send, receive messages if message passing model
to host name or process name
» From client to server
– Shared-memory model create and gain access to
memory regions
– transfer status information
– attach and detach remote devices
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.38
Types of System Calls (Cont.)
• Protection
– Control access to resources
– Get and set permissions
– Allow and deny user access
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.39
POSIX standard
• Portable Operating System Interface for UNIX
» An attempt to standardize a “UNIXy” interface
• Conformance: IEEE POSIX 1003.1 and ISO/IEC 9945
– Latest version from 2008
– Originally one document consisting of a core programming inteface –
now 19 separate docs
– Many OSes provide “partial conformance” (including Linux)
• What does POSIX define?
– POSIX.1: Core Services
» Process Creation and Control
» Signals
» Floating Point Exceptions, Segmentation/memory violations, illegal
instructions, Bus Erors
» Timers
» File and Directory Operations
» Pipes
» C Library (Standard C)
» I/O Port Interface and Control
» Process Triggers
– POSIX.1b: Realtime Extensions
– POSIX.2: Shell and Utilities
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.40
POSIX (cont)
• Process Primitives:
– fork, execl, execlp, execv, execve, execvp, wit, waitpid
– _exit, kill, sigxxx, alarm, pause, sleep….
• Example file access primitives:
– opendir, readdir, rewinddir, closedir, chdir, getcwd, open, creat, umask, link,
mkdir, unlink, rmdir, rename, stat, fstat, access, fchmod, chown, utime,
ftruncate,pathconf,fpathconf
• I/O primitives:
– pipe, dup, dup2, close, read, write, fcntl, lseek, fsync
• C-Language primitives:
– abort, exit, fclose, fdopen, fflush, fgetc, fgets, fileno, fopen, fprintf, fputc,
fputs, fread, freopen, fscanf, fseek, ftell, fwrite, getc, getchar, gets, perror,
printf, putc, putchar, puts, remove, rewind, scanf, setlocale, siglongjmp,
sigsetjmp, tmpfile, tmpnam, tzset
• Synchronization:
– sem_init, sem_destroy, sem_wait, sem_trywait, sem_post, pthread_mutex_init,
pthread_mutex_destroy, pthread_mutex_lock, pthread_mutex_trylock,
pthread_mutex_unlock
• Memory Management
– mmap, mprotect, msync, munmap
• ETC……
• How to get information on a system call?
– Type “man callname”, i.e. “man open”
– System calls are in section “2” of the man pages
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.41
Portability
• POSIX does provide some portability
– But is still pretty high level
– Does not specify file systems, network interfaces,
power management, other important things
– Many variations in compilers, user programs,
libraries, other build environment aspects
• UNIX Portability:
–
–
–
–
2/6/13
C-preprocessor conditional compilation
Conditional and multi-target Makefile Rules
GNU configure scripts to generate Makefiles
Shell environment variables (LD_LIBRARY_PATH,
LD_PRELOAD, others)
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.42
Examples of Windows and
Unix System Calls
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.43
Standard C Library Example
• C program invoking printf() library call, which
calls write() system call
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.44
Summary
• Processes have two parts
– Threads (Concurrency)
– Address Spaces (Protection)
• Concurrency accomplished by multiplexing CPU Time:
– Unloading current thread (PC, registers)
– Loading new thread (PC, registers)
– Such context switching may be voluntary (yield(), I/O
operations) or involuntary (timer, other interrupts)
• Protection accomplished restricting access:
– Memory mapping isolates processes from each other
– Dual-mode for isolating I/O, other resources
• System-Call interface
– This is the I/O for the process “virtual machine”
– Accomplished with special trap instructions which vector off
a table of system calls
– Usually programmers use the standard API provided by the C
library rather than direct system-call interface
• POSIX interface
– An attempt to standardize “unixy” Oses
2/6/13
Kubiatowicz CS194-24 ©UCB Fall 2013
Lec 4.45