Transcript Operating Systems

INF1060:
Introduction to Operating Systems and Data Communication
Operating Systems:
Introduction
Pål Halvorsen
12/9 - 2007
Overview
 Basic execution environment – an Intel example
 What is an operating system (OS)?
 (Very) Short history
 OS components and services
(extended in later lectures)
 Booting
 Kernel organization
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Hardware
 Central Processing Unit (CPU)
 Memory (cache(s), RAM, ROM, Flash, …)
 I/O Devices (network cards, disks, floppy, CD, …)
 Links (interconnects, busses, …)
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Example:
Intel Hub Architecture (850 Chipset)
Intel D850MD Motherboard:
Source: Intel® Desktop Board D850MD/D850MV Technical Product Specification
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Example:
Intel Hub Architecture (850 Chipset)
Intel D850MD Motherboard:
Source: Intel® Desktop Board D850MD/D850MV Technical Product Specification
mouse, keyboard, parallel, serial,
network and USB connectors
Video
PCI Connectors (slots)
Memory Controller
Hub
AGP slot
Pentium 4 socket
I/O Controller Hub
RDRAM
interface
PCI
bus
RAMBUS RDRAM –
2 banks (4 slots)
Firmware Hub –
including BIOS
Power connector
Speaker
Battery
University of Oslo
Diskette connector
IDE drive connectors
INF1060, Autumn 2007, Pål Halvorsen
Example:
Intel Hub Architecture (850 Chipset)
application
Pentium 4
Processor
file system
registers
cache(s)
disk
system bus
(64-bit, 400/533 MHz
~24-32 Gbps)
RDRAM
memory
controller
hub
RAM interface
(two 64-bit, 200 MHz
 ~24 Gbps)
RDRAM
RDRAM
RDRAM
hub interface
(four 8-bit, 66 MHz
 2 Gbps)
I/O
controller
hub
University of Oslo
PCI slots
PCI bus
(32-bit, 33 MHz
 1 Gbps)
PCI slots
PCI slots
INF1060, Autumn 2007, Pål Halvorsen
disk
Intel 32-bit Architecture (IA32): Basic Execution Environment
 Address space: 1 – 236 (64 GB),
each prosess may have a linear address space of 4 GB (232)
 Basic program execution registers:
−
−
−
−
8
6
1
1
general purpose registers (data: EAX, EBX, ECX, EDX, address: ESI, EDI, EBP, ESP)
segment registers (CS, DS, SS, ES, FS and GS)
GPRs:
flag register (EFLAGS)
EAX:
X
PUSH %eax
instruction pointer register (EIP)
Y
EBX:
 Stack – a continuous array of memory locations
−
−
−
−
−
Current stack is referenced by the SS register
ESP register – stack pointer
EBP register – stack frame base pointer (fixed reference)
PUSH – stack grow, add item (ESP decrement)
POP – remove item, stack shrinks (ESP increment)
 Several other registers like Control, MMX,
PUSH %ebx
PUSH %ecx
<do something>
POP %ecx
POP %ebx
POP %eax
XMM, FPU, MTRR, MSR, SSE, SSE2 and performance monitoring
Z
ECX:
EDX:
ESI:
EDI:
EBP:
ESP: see arrow
STACK:
0x0...
Z
Y
X
...
0xfff...
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Intel 32-bit Architecture (IA32): Basic Execution Environment
code segment:
 Example:
…
8048314 <main>:
main (void)
{
int a = 4, b = 2, c = 0;
c = a + b;
}
stack:
8048314:
push
%ebp
8048315:
mov
%esp,%ebp
8048317:
sub
$0x18,%esp
804831a:
and
$0xfffffff0,%esp
804831c:
mov
$0x0,%eax
insert value 4 in variable a on stack:
0xfffffffc = -(0xffffffff – 0xfffffffc) = -0x4
8048322:
sub
%eax,%esp
8048324:
movl
$0x4,0xfffffffc(%ebp)
a’s memory address = EBP - 4
804832b:
movl
$0x2,0xfffffff8(%ebp)
8048332:
movl
$0x0,0xfffffff4(%ebp)
8048339:
mov
0xfffffff8(%ebp),%eax
sub 24 (0x18) bytes
804833c:
add
0xfffffffc(%ebp),%eax
(add space for 24 bytes)
804833f:
mov
%eax,0xfffffff4(%ebp)
8048342:
leave
8048343:
ret
0x0...
sub 8 bytes
0
6
…
2
4
old EBP
...
...
...
University of Oslo
EAX:
Accumulator for operands and results data
60
2
ESP:
0xfff...
Stack pointer
0xffffffd0
0xffffffd8
0xfffffff4
0xfffffff0
INF1060, Autumn 2007, Pål Halvorsen
EBP:
???
0xfffffff0
Pointer to data on stack
EPI:
804832b
8048314
8048317
8048315
8048324
8048322
8048339
8048332
8048342
8048343
804831a
804831c
804833c
804833f
…
Pointer to next instruction to be executed
C Function Calls & Stack
 C provides call-by-value only:
a copy of the data value is passed to the function for processing –
original is NOT changed (can simulate by-reference using pointers)
 A calling function does
− push the parameters into stack in reverse order
− push return address (current EIP value) onto stack
 When called, a C function does
− push frame pointer (EBP) into stack - saves frame pointer register and gives easy return if necessary
− let frame pointer point at the stack top, i.e., point at the saved stack pointer (EBP = ESP)
− shift stack pointer (ESP) upward (to lower addresses) to allocate space for local variables
 When returning, a C function does
−
−
−
−
put return value in the return value register (EAX)
copy frame pointer into stack pointer - stack top now contains the saved frame pointer
pop stack into frame pointer (restore), leaving the return program pointer on top of the stack
the RET instruction pops the stack top into the program counter register (EIP), causing the CPU to
execute from the "return address" saved earlier
 When returned to calling function, it does
− copy the return value into right place
− pop parameters – restore the stack
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
C Function Calls & Stack
 Example:
int add (int a, int b)
{
return a + b;
}
main (void)
{
1. Pop return instruction pointer
int c = 0;
into the EIP register
2. Release
c = add(4
, 2);parameters (ESP)
3. Resume caller execution
}
stack:
0x0...
“main” EBP
804834a
4
2
1.
2.
3.
6
0
old EBP
...
...
University of Oslo
Push EIP register
Loads the offset of the called
procedure in the EIP register
Begin execution
code segment:
…
8048314 <add>:
8048314:
push
%ebp
8048315:
mov
%esp,%ebp
8048317:
mov
0xc(%ebp),%eax
804831a:
add
0x8(%ebp),%eax
804831d:
pop
%ebp
804831e:
ret
804831f <main>:
804831f:
push
%ebp
8048320:
mov
%esp,%ebp
8048322:
sub
$0x18,%esp
8048325:
and
$0xfffffff0,%esp
8048328:
mov
$0x0,%eax
804832d:
sub
%eax,%esp
804832f:
movl
$0x0,0xfffffffc(%ebp)
8048336:
movl
$0x2,0x4(%esp)
804833e:
movl
$0x4,(%esp)
8048345:
call
8048314 <add>
804834a:
mov
%eax,0xfffffffc(%ebp)
804834d:
leave
804834e:
ret
804834f:
nop
...
0xfff...
INF1060, Autumn 2007, Pål Halvorsen
Different Hardware
University of Oslo
Application program
Application program
Operating
System
Application
Application
Operating
System
Hardware X
Hardware Y
INF1060, Autumn 2007, Pål Halvorsen
Many Concurrent Tasks
 Better utilization
Application program layer
− many concurrent
processes
• performing different
tasks
• using different parts of
the machine
Web browser
Spreadsheet
Word
processor
E-mail
− many concurrent users
Presentation
graphics
 Challenges
−
−
−
−
“concurrent” access
protection/security
fairness
…
OperatingSystem
system layer
Operating
Layer
Hardware layer
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
What is an Operating System (OS)?
 “An operating system (OS) is a collection of programs that acts as an
intermediary between the hardware and its user(s), providing a high-level
interface to low level hardware resources, such as the CPU, memory, and
I/O devices. The operating system provides various facilities and services
that make the use of the hardware convenient, efficient, and safe”
Lazowska, E. D.: Contemporary Issues in Operating Systems , in: Encyclopedia of Computer Science, Ralston, A., Reilly, E. D. (Editors), IEEE Press, 1993, pp.980
 It is an extended machine (top-down view)
− Hides the messy details
− Presents user with a virtual machine, easier to use
 It is a resource manager (bottom-up view)
− Each program gets time with the resource
− Each program gets space on the resource
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
user
application
operating
system
hardware
Where do we find OSes?
Computers
Game Boxes
Phones
cameras,
other vehicles/crafts,
set-top boxes,
watches,
sensors,
…
Cars
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Operating System Categories
 Single-user, single-task:
historic, but rare (only a few PDAs use this)
 Single-user, multi-tasking:
PCs and workstations may be configured like this
 Multi-user, multi-tasking:
used on large, old mainframes and PCs, workstations and servers today
 Distributed OSes:
support for administration of distributed resources
 Real-time OSes:
support for systems with real-time requirements like cars, nuclear reactors, etc.
 Embedded OSes:
built into a device to control a specific type of equipment like cellular phones, micro
waves, etc.
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
History
 OSes have evolved over the last 60 years
 Early history (’40s and early ’50s):
− first machines did not include OSes
− programmed using mechanical switches or wires
 Second generation (’50s and ’60s):
− transistors introduced in mid-’50s
− batch systems
− card readers
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
History
 Third generation (mid-’60s to the ’80s)
− integrated circuits and simple multiprogramming
− timesharing
− graphical user interface
− UNIX (’69-’70)
− BSD (’77)
 Newer times (’80s to present)
− personal computers & workstations
− MS-DOS (’82), Win (’85), Minix (’87), Linux (’91), Win95, …
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Why Study OSes?
 Understand how computers work under the hood
− “you need to understand the system at all abstraction levels or you don’t” (Yale Patt)
 Easier to do things right and efficient if one knows what happens
 Magic to provide infinite CPU cycles, memory, devices
and networked computing
 Tradeoffs between performance and functionality,
division of labor between HW and SW
 OSes are key components in many systems
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Primary Components
 Apparent to user
Application program layer
− Shell
− File system
− Device management
Operating system layer
 Transparent
− Processor management
− Memory management
− Communication services
User interface
(shell)
File
management
Device
management
Processor
(or process)
management
Memory
management
Communication
services
Hardware layer
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Primary Components
File Management:
the file system provides a mechanism
Application
program
layer and
for the
user to create,
delete, modify
manipulate files
User Interface:
Operating system layer
Device Management:
provide a mechanism for user and
Userwith
interface
application to communicate
OS
(shell)
and use the machine resources
Processor
Management of processes:
(or process)
provide a mechanism for management
the system
to efficiently and fair manage the
machine CPU cycles for the running
processes
File
management
Memory
management
provide the system with means to
Device
control
the systems peripheral devices
management
like keyboard, display, printer and disk
Communication
Communication:
services
provide
a mechanism for the system
communicate with other processes (on
same or another machine)
Hardware layer
Memory Management:
provide a mechanism for the system
to efficiently manage the system’s
memory recourses – allocating space
to processes
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Note: this list of components is
not complete. Some OSes have
fewer, others more. Some have
sub-components
Device Management
 The OS must be able to control pheripal devices such as disk, keyboard,
network cards, screen, speakers, mouse, memory sticks, ...
 Device controllers often have registers to hold status, give commands, ...
 Each type is different and require device-spesific software
 The software talking to the controller and giving commands is often called a
device driver
− usually running within the kernel
− mostly provided by the device vendors
− translating device-independent commands, e.g.,
read from file on disk: logical block number  device, cylinder, head, sector(s)
 A huge amount of code (95% of the Linux code!!??)
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Interfaces
 A point of connection between components
 The OS incorporates logic that support interfaces with both
hardware and applications, e.g.,
− command line interface, e.g., a shell
− graphical user interface (GUI)
• interface consisting of windows, icons, menus and pointers
• often not part of the OS (at least not kernel), but an own program
−…
 Example: X (see man X)
− network transparent windows system running on most ANSI C and POSIX
(portable OS interface for UNIX) compliant systems
− uses inter process communication to get input from and send output to
various client programs
− xdm (X Display Manager) – usually set by administrator to run
automatically at boot time
− xinit – manually starting X (startx, x11, xstart, …)
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Windows Interfaces
Application
program
User
The GUI incorporates a
command line shell similar
to the MS-DOS interface
Shell
API
GUI
Other operating system components
Operating system layer
Hardware layer
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Applications access HW
through the API consisting of
a set of routines, protocols and
other tools
UNIX Interfaces
Applications are access HW through
the API consisting of a set of routines,
protocols and other tools (e.g., POSIX –
portable OS interface for UNIX)
A user can interact with the system
through the application interface or
using a command line prosessed by
a shell (not really a part of the OS)
Application
program
User
POSIX
(API)
Shell
GUI
Other operating system components
A plain command line interface may
be hard to use. Many UNIX systems
therefore have a standard graphical
interface (X Windows) which can run
a desktop system (like KDE, Gnome,
Fvwm, Afterstep, …)
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Operating system layer
Hardware layer
System Calls
Linux system calls
(2.4.19):
 The interface between the OS and
users is defined by a set of system
calls
 Making a system call is similar to a
procedure call, but system calls
enter the kernel:
application
application
application
system call interface
user space
kernel space
OS components
University of Oslo
sys_prctl(int option,
sys_acct(const
sys_socket(int
sys_fchdir(unsigned
family,
char *name)
unsigned
intintfd)
type,long
int protocol)
arg2, unsigned long arg3,
sys_acct(const char
sys_socketpair(int
sys_chroot(const
sys_sysctl(struct
__sysctl_args
char
family,
* filename)
* filename)
int type,
*args)
int protocol, int usockvec[2])
sys_capget(cap_user_header_t
sys_bind(int
sys_open(const
sys_sysctl(struct
fd, char
struct
__sysctl_args
* sockaddr
filename,*args)
header,
*umyaddr,
int flags,
cap_user_data_t
int
intmode)
addrlen) dataptr)
sys_capset(cap_user_header_t
sys_listen(int
sys_creat(const
ys_time(int
* fd,
tloc)
char
int backlog)
* pathname,
header,
int mode)
const cap_user_data_t data)
sys_exit(int error_code)
sys_accept(int
sys_close(unsigned
sys_stime(int
*fd,
tptr)
struct
int fd)
sockaddr *upeer_sockaddr, int *upeer_addrlen)
sys_wait4(pid_t fd,
sys_connect(int
sys_vhangup(void)
sys_gettimeofday(struct
pid,unsigned
structtimeval
sockaddr
int *tv,
* stat_addr,
*uservaddr,
struct timezone
intint
options,
addrlen)
*tz) struct rusage * ru)
sys_waitpid(pid_t pid,unsigned
sys_getsockname(int
sys_lseek(unsigned
sys_settimeofday(struct
intfd,fd,
timeval
struct
off_t sockaddr
int
offset,
*tv,
* stat_addr,
struct
unsigned
*usockaddr,
timezone
int
intoptions)
origin)
*tz)
int *usockaddr_len)
sys_futex(void *uaddr,
sys_getpeername(int
sys_llseek(unsigned
sys_adjtimex(struct
timex
int
fd,int
fd,
struct
*txc_p)
op,
unsigned
int
sockaddr
val,long
struct
*usockaddr,
offset_high,
timespec int
*utime)
*usockaddr_len)
sys_sysinfo(struct
sys_sendto(int
sys_read(unsigned
sys_alarm(unsigned
fd, sysinfo
void
int
intfd,
*seconds)
buff,
char
*info)size_t
* buf, len,
size_t
unsigned
count) flags,
sys_getitimer(int
sys_send(int
sys_write(unsigned
sys_getpid(void)
fd, void
which,
int* fd,
buff,
struct
const
size_t
itimerval
char
len,
* buf,
unsigned
*value)
size_tflags)
count)
sys_setitimer(int which,
sys_recvfrom(int
sys_readv(unsigned
sys_getppid(void)
fd, long
voidstruct
fd,
* ubuf,
const
itimerval
size_t
structsize,
*value,
iovec
unsigned
* vector,
flags,
sys_sync(void);
sys_recv(int
sys_writev(unsigned
sys_getuid(void)
fd, void
/* it's*long
really
ubuf,
fd,int
size_t
const
*/ size,
structunsigned
iovec * vector,
flags)
sys_syslog(int type,fd,
sys_setsockopt(int
sys_pread(unsigned
sys_geteuid(void)
char
intintfd,*level,
char
buf, int
int
* buf,
optname,
len)
char *optval, int optlen)
sys_nice(int increment)
sys_getsockopt(int
sys_pwrite(unsigned
sys_getgid(void)
fd,intintfd,level,
const
intchar
optname,
* buf, char *optval, int *optlen)
sys_sched_setscheduler(pid_t
sys_shutdown(int
sys_getdents(unsigned
sys_getegid(void)
fd, intint
how)
fd, void
pid, int
* dirent,
policy,unsigned int count)
sys_sched_setparam(pid_t
sys_sendmsg(int
sys_getdents64(unsigned
sys_gettid(void)
fd, structint
msghdr
pid,
fd,struct
void
*msg,
*sched_param
dirent,
unsigned
unsigned
flags)
*param)
int count)
sys_sched_getscheduler(pid_t
sys_recvmsg(int
sys_poll(struct
sys_nanosleep(struct
pollfd
fd, struct
*timespec
ufds,
msghdr
unsigned
pid)
*rqtp,
*msg,
struct
int unsigned
nfds,
timespec
longint
timeout)
*rmtp)
flags)
sys_sched_getparam(pid_t
sys_socketcall(int
sys_stat(char
sys_chown(const
* filename,
char
call, *,
unsigned
uid_t,gid_t);
struct
pid, struct
__old_kernel_stat
long *args)
sched_param* *param)
statbuf)
sys_sched_setaffinity(pid_t
sys_tux
sys_newstat(char
sys_lchown(const
(unsigned*char
int
filename,
action,
*, uid_t,gid_t);
pid,
user_req_t
struct
unsigned
stat **u_info)
int
statbuf)
len,
sys_sched_getaffinity(pid_t
sys_io_setup(unsigned
sys_lstat(char
sys_fchown(unsigned
* filename,
int,
nr_reqs,
uid_t,gid_t);
struct
pid, aio_context_t
unsigned
__old_kernel_stat
int len,
*ctxp)
* statbuf)
sys_sched_yield(void)
sys_io_destroy(aio_context_t
sys_newlstat(char
sys_setregid(gid_t,
*gid_t);
filename, ctx)
struct stat * statbuf)
sys_sched_get_priority_max(int
sys_io_submit(aio_context_t
sys_fstat(unsigned
sys_setgid(gid_t);
int fd, struct
ctx_id,
policy)
__old_kernel_stat
long nr,
* statbuf)
sys_sched_get_priority_min(int
sys_io_cancel(aio_context_t
sys_newfstat(unsigned
sys_setreuid(uid_t,
uid_t);
int fd,ctx_id,
struct
policy)
struct
stat * iocb
statbuf)
*iocb,
sys_sched_rr_get_interval(pid_t
sys_io_getevents(aio_context_t
sys_readlink(const
sys_setuid(uid_t);
char * path, char
ctx_id,
pid, *struct
buf, timespec
int bufsiz)*interval)
sys_ni_syscall(void)
sys_sync(void)
sys_stat64(char
sys_setresuid(uid_t,
* filename,
uid_t, uid_t);
struct stat64 * statbuf, long flags)
sys_setpriority(int* which,
sys_fsync(unsigned
sys_lstat64(char
sys_setresgid(gid_t,
filename,
int
gid_t,
fd)intgid_t);
struct
who, int
stat64
niceval)
* statbuf, long flags)
sys_getpriority(int which,
sys_fdatasync(unsigned
sys_fstat64(unsigned
sys_setfsuid(uid_t);
long
intint
fd,
fd)
who)
struct stat64 * statbuf, long flags)
sys_reboot(intoption,
sys_bdflush(int
sys_sysfs(int
sys_setfsgid(gid_t);
magic1,
func, unsigned
long
int data)
magic2,
long unsigned
arg1, unsigned
int cmd,
long
void
arg2)
* arg)
sys_setregid(gid_t
sys_getcwd(char
sys_ustat(dev_t
sys_chown16(const
dev,
*buf,
rgid,
char
struct
unsigned
gid_t
* filename,
ustat
egid)
long
* ubuf)
old_uid_t
size)
user, old_gid_t group)
sys_setgid(gid_tout_fd,
sys_uselib(const
sys_sendfile(int
sys_lchown16(const
char
gid)char
* library)
int* in_fd,
filename,
off_told_uid_t
*offset, size_t
user, old_gid_t
count) group)
sys_setreuid(uid_t fd,
sys_dup2(unsigned
sys_readahead(int
sys_fchown16(unsigned
ruid,
intloff_t
oldfd,
uid_t
int fd,
offset,
unsigned
euid)
old_uid_t
size_t
intuser,
count)
newfd)
old_gid_t group)
sys_setuid(uid_t uid)
sys_dup(unsigned
sys_msync(unsigned
sys_setregid16(old_gid_t
int long
fildes)
rgid,
start,old_gid_t
size_t len,
egid)
int flags)
sys_setresuid(uid_t int
sys_fcntl(unsigned
sys_madvise(unsigned
sys_setgid16(old_gid_t
ruid,
fd,
long
gid)
uid_t
unsigned
start,
euid,
size_t
int
uid_t
cmd,
len,
suid)
unsigned
int behavior)
long arg)
sys_getresuid(uid_t *ruid,
sys_fcntl64(unsigned
sys_mincore(unsigned
sys_setreuid16(old_uid_t
int
long
fd,
ruid,
uid_t
start,
unsigned
old_uid_t
*euid,
size_t
int
uid_t
len,
euid)
cmd,*suid)
unsigned long arg)
sys_setresgid(gid_t
sys_nfsservctl(int
sys_mlock(unsigned
sys_setuid16(old_uid_t
cmd,
rgid,
long
void
uid)
gid_t
start,
*argp,
egid,
size_t
void
gid_t
len)
*resp)
sgid)
sys_getresgid(gid_tint
sys_ioctl(unsigned
sys_munlock(unsigned
sys_setresuid16(old_uid_t
*rgid,
fd,
long
unsigned
ruid,
gid_t
start,
old_uid_t
*egid,
size_t
int cmd,
gid_t
len)
euid,
unsigned
*sgid)
old_uid_t
longsuid)
arg)
sys_setfsuid(uid_t
sys_flock(unsigned
sys_mlockall(int
sys_getresuid16(old_uid_t
flags)
uid)
int fd, unsigned
*ruid, old_uid_t
int cmd)*euid, old_uid_t *suid)
sys_setfsgid(gid_t char
sys_mknod(const
sys_munlockall(void)
sys_setresgid16(old_gid_t
gid) * filename,
rgid, old_gid_t
int mode,
egid,
dev_t
old_gid_t
dev) sgid)
sys_times(struct char
sys_mkdir(const
sys_brk(unsigned
sys_getresgid16(old_gid_t
tms
long**brk)
tbuf)
pathname,
*rgid, old_gid_t
int mode)
*egid, old_gid_t *sgid)
sys_setpgid(pid_tchar
sys_rmdir(const
sys_munmap(unsigned
sys_setfsuid16(old_uid_t
pid,*pid_t
pathname)
long
uid)pgid)
addr, size_t len)
sys_getpgid(pid_tchar
sys_unlink(const
sys_mprotect(unsigned
sys_setfsgid16(old_gid_t
pid)* long
pathname)
gid)start, size_t len, unsigned long prot)
sys_getpgrp(void) char
sys_symlink(const
sys_mremap(unsigned
sys_getgroups16(int
gidsetsize,
long
* oldname,
addr,
old_gid_t
const char
*grouplist)
* newname)
sys_getsid(pid_t
sys_link(const
sys_swapoff(const
sys_setgroups16(int
char
pid)
char
*gidsetsize,
oldname,
* specialfile)
const
old_gid_t
char*grouplist)
* newname)
sys_setsid(void) char * oldname,
sys_rename(const
sys_swapon(const
sys_getuid16(void)
specialfile,const
int swap_flags)
char * newname)
sys_getgroups(int
sys_umount(char
sys_msgget
sys_geteuid16(void)
(key_t*gidsetsize,
key,
name,
intint
msgflg)
gid_t
flags)*grouplist)
sys_setgroups(int
sys_oldumount(char
sys_msgctl
sys_getgid16(void)
(int msqid,
gidsetsize,
* name)
int cmd,
gid_t
struct
*grouplist)
msqid_ds *buf)
sys_newuname(struct
sys_mount(char
sys_msgsnd
sys_getegid16(void)
(int *msqid,
dev_name,
new_utsname
struct char
msgbuf
* *dir_name,
*msgp,
name) size_t
char *msgsz,
type, int msgflg)
sys_sethostname(char
sys_pivot_root(const
sys_msgrcv
sys_utime(char
(int *msqid,
filename,
char
*name,
struct
*new_root,
struct
msgbuf
int utimbuf
len) *msgp,
const
* times)
char
size_t
*put_old)
msgsz,
sys_gethostname(char
sys_statfs(const
sys_semget
sys_utimes(char
(key_t
char
* filename,
key,
* *name,
path,
int nsems,
struct
struct
int len)
timeval
int
statfs
semflg)
**buf)
utimes)
sys_setdomainname(char
sys_fstatfs(unsigned
sys_semctl
sys_access(const
(int semid,
charint*intfd,
filename,
*name,
semnum,
struct int
statfs
intint
len)
mode)
cmd,
* buf)
union semun arg)
sys_getrlimit(unsigned
sys_truncate(const
sys_semop
sys_chdir(const
(int semid,
charchar
* struct
filename)
int
* resource,
path,
sembuf
unsigned
struct
*tsops,
long
rlimit
unsigned
length)
*rlim) nsops)
sys_old_getrlimit(unsigned
sys_ftruncate(unsigned
sys_shmget
sys_fchmod(unsigned
(key_t key,
intint
size_t
fd,fd,
intmode_t
unsigned
resource,
size, int
mode)
shmflg)
long
structlength)
rlimit *rlim)
sys_setrlimit(unsigned
sys_truncate64(const
sys_shmctl
sys_chmod(const
(int shmid,
charchar
*
intfilename,
resource,
cmd,
* path,
struct
mode_t
loff_t
struct
shmid_ds
length)
rlimit
mode)
*rlim)
*buf)
sys_getrusage(int
sys_ftruncate64(unsigned
sys_shmat
sys_chown(const
(int shmid,
char
who,char
*struct
filename,
int
*shmaddr,
fd,
rusage
loff_t
uid_t
*ru)
length)
int
user,
shmflg,
gid_tulong
group)
*raddr)
sys_umask(int
sys_shmdt
sys_lchown(const
(char
mask)
*shmaddr)
char * filename, uid_t user, gid_t group)
sys_semget (key_t key,
sys_fchown(unsigned
intint
fd,nsems,
uid_t user,
int semflg)
gid_t group)
sys_semop (int semid, struct sembuf *sops, unsigned nsops)
sys_semctl (int semid, int semnum, int cmd, union semun arg)
sys_msgget (key_t key, int msgflg)
sys_msgsnd (int msqid, struct msgbuf *msgp, size_t msgsz, int msgflg)
sys_msgrcv (int msqid, struct msgbuf *msgp, size_t msgsz, long msgtyp,
sys_msgctl (int msqid, int cmd, struct msqid_ds *buf)
sys_shmget (key_t key, size_t size, int shmflag)
INF1060, Autumn 2007, Pål Halvorsen
System Calls: read

C example:
count = read(fd,buffer,nbyte)
1.
push parameters on stack
2.
call library code
register
put system call number in register
memory (stack)
3.
4.
count = read (fd , buffer , nbytes)
kernel space
system call
handler
X
resume process
University of Oslo
buffer
user space
kernel examines system call number
finds requested system call handler
execute requested operation
increase instruction pointer
remove parameters from stack
application
nbytes
buffer
fd
return to library and clean up


6.
X (read)
call kernel (TRAP)



5.
read library
procedure
sys_read()
INF1060, Autumn 2007, Pål Halvorsen
Booting
 Memory is a volatile, limited resource: OS usually on disk
 Most motherboards contain a basis input/output system (BIOS)
chip (often flash RAM) – stores instructions for basic HW
initialization and management, and initiates the …
 ... bootstrap: loads the OS into memory
− read the boot program from a known location on secondary storage
typically first sector(s), often called master boot record (MBR)
− run boot program
• read root file system and locate file with OS kernel
• load kernel into memory
• run kernel
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Booting
1.
2.
3.
4.
5.
Gather HW information and set up system
Load data from boot sector
Execute boot program an CPU
Load OS from disk
Run OS
boot
OS
boot
OS
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
User Level vs. Kernel Level (Protection)
 Many OSes distinguish user and kernel level,
i.e., due to security and protection
 Usually, applications and many sub-systems run in user mode
(pentium level 3)
−
−
−
−
real mode
not allowed to access HW or device drivers directly, only through an API
access to assigned memory only
limited instruction set
 OSes run in kernel mode
(under the virtual machine abstraction, pentium level 0)
−
−
−
−
protected mode
access to the entire memory
all instructions can be executed
bypass security
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Interrupt Program Execution
CPU
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Interrupts
 Interrupts are electronic signals that (usually) result in a forced
transfer of control to an interrupt handling routine
− alternative to polling
− caused by asynchronous events like finished disk operations, incoming
network packets, expired timers, …
− an interrupt descriptor table (IDT) associates each interrupt with a code
descriptor (pointer to code segment)
− can be disabled or masked out
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Exceptions
 Another way for the processor to interrupt program
execution is exceptions
− caused by synchronous events generated when the processor detects a
predefined condition while executing an instruction
− TRAPS: the processor reaches a condition the exception handler can
handle (e.g., overflow, break point in code like making a system call, …)
− FAULTS: the processor reaches a fault the exception handler can correct
(e.g., division by zero, wrong data format, …)
− ABORTS: terminate the process due to an unrecoverable error
(e.g., hardware failure) which the process itself cannot correct
− the processor responds to exceptions (i.e., traps and faults) essentially as
for interrupts
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Interrupt (and Exception) Handling

The IA-32 has an IDT with 256 entries for interrupts and exceptions
−
−

32 (0 - 31) predefined and reserved
224 (32 - 255) is user defined
Each interrupt is associated with a code segment through
the IDT and a unique index value giving management like this:
1.
process running while interrupt occur
2.
capture state, switch control
and find right interrupt handler
3.
execute the interrupt handler
4.
restore interrupted process
5.
continue execution
University of Oslo
user
kernel
disk interrupt (x)
INF1060, Autumn 2007, Pål Halvorsen
IDT:
Interrupt routines:
OS Organization
 No standard describing how to organize a kernel (as it is for compilers,
communication protocols, etc.) and several approaches exist, e.g.:
 Monolithic kernels (“the big mess”):
−
−
−
−
written as a collection of functions linked into a single object
usually efficient (no boundaries to cross)
large, complex, easy to crash
UNIX, Linux, …
 Micro kernels
− kernel with minimal functionality (managing interrupts, memory, processor)
− other services are implemented in server processes running in user space
used in a client-server model
− lot of message passing
(inefficient)
− small, modular,
extensible, portable, …
− MACH, L4, Chorus, …
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen
Summary
 OSes are found “everywhere” and provide virtual machines and
work as a resource managers
 Many components providing different services
 The user access the services using an interface like system calls
 In the next lectures, we look closer on some of the main
components and abstractions in an OS
−
−
−
−
processes management
memory management
storage management
local interprocess communication
− intercomputer network communication is covered in the last part of the
course
University of Oslo
INF1060, Autumn 2007, Pål Halvorsen