INF 1060 Introduction to Operating Systems and Data

INF 1060: 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 INF 1060, 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 INF 1060, Autumn 2007, Pål Halvorsen

Example: Intel Hub Architecture (850 Chipset) Intel D 850 MD Motherboard: Source: Intel® Desktop Board D 850 MD/D 850 MV Technical Product Specification University of Oslo INF 1060, Autumn 2007, Pål Halvorsen

Example: Intel Hub Architecture (850 Chipset) Intel D 850 MD Motherboard: Source: Intel® Desktop Board D 850 MD/D 850 MV Technical Product Specification Video mouse, keyboard, parallel, serial, network and USB connectors PCI Connectors (slots) Memory Controller Hub sy st em bu s AGP slot I/O Controller Hub e PCI bus b c hu rfa te in RDRAM interface Pentium 4 socket RAMBUS RDRAM – 2 banks (4 slots) Firmware Hub – including BIOS Power connector Speaker Battery University of Oslo Diskette connector IDE drive connectors INF 1060, 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 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 INF 1060, Autumn 2007, Pål Halvorsen disk

Intel 32 -bit Architecture (IA 32): 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) PUSH %ebx PUSH %ecx <do something> POP %ecx POP %ebx POP %eax Z ECX: EDX: ESI: EDI: EBP: ESP: see arrow STACK: § Several other registers like Control, MMX, XMM, FPU, MTRR, MSR, SSE 2 and performance monitoring : ter oin Pp ES University of Oslo INF 1060, Autumn 2007, Pål Halvorsen 0 x 0. . . Z Y X. . . 0 xfff. . .

Intel 32 -bit Architecture (IA 32): Basic Execution Environment code segment: § Example: … 8048314 <main>: objdu main (void) mp -d { int a = 4, b = 2, c = 0; c = a + b; } stack: 8048314: push %ebp 8048315: mov %esp, %ebp 8048317: sub $0 x 18, %esp 804831 a: and $0 xfffffff 0, %esp 804831 c: mov $0 x 0, %eax insert value 4 in variable a on stack: 0 xfffffffc = -(0 xffff – 0 xfffffffc) = -0 x 4 8048322: sub %eax, %esp 8048324: movl $0 x 4, 0 xfffffffc(%ebp) a’s memory address = EBP - 4 804832 b: movl $0 x 2, 0 xfffffff 8(%ebp) 8048332: movl $0 x 0, 0 xfffffff 4(%ebp) 8048339: mov 0 xfffffff 8(%ebp), %eax 804833 c: add 0 xfffffffc(%ebp), %eax 804833 f: mov %eax, 0 xfffffff 4(%ebp) 8048342: leave 8048343: ret 0 x 0. . . sub 24 (0 x 18) bytes (add space for 24 bytes) sub 8 bytes 0 6 … 2 4 old EBP. . University of Oslo EAX: Accumulator for operands and results data 60 2 ESP: 0 xfff. . . Stack pointer 0 xffffffd 0 0 xffffffd 8 0 xfffffff 4 0 xfffffff 0 INF 1060, Autumn 2007, Pål Halvorsen EBP: ? ? ? 0 xfffffff 0 Pointer to data on stack EPI: 804832 b 8048314 8048317 8048315 8048324 8048322 8048339 8048332 8048343 804831 a 804831 c 804833 f … 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 INF 1060, Autumn 2007, Pål Halvorsen

C Function Calls & Stack § Example: int add (int a, int b) { return a + b; objdu } mp code segment: … 8048314 <add>: -d 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: 0 x 0. . . “main” EBP 804834 a 4 2 1. 2. 6 0 old EBP. . . University of Oslo 3. Push EIP register Loads the offset of the called procedure in the EIP register Begin execution 8048314: push %ebp 8048315: mov %esp, %ebp 8048317: mov 0 xc(%ebp), %eax 804831 a: add 0 x 8(%ebp), %eax 804831 d: pop %ebp 804831 e: ret 804831 f <main>: 804831 f: push %ebp 8048320: mov %esp, %ebp 8048322: sub $0 x 18, %esp 8048325: and $0 xfffffff 0, %esp 8048328: mov $0 x 0, %eax 804832 d: sub %eax, %esp 804832 f: movl $0 x 0, 0 xfffffffc(%ebp) 8048336: movl $0 x 2, 0 x 4(%esp) 804833 e: movl $0 x 4, (%esp) 8048345: call 8048314 <add> 804834 a: mov %eax, 0 xfffffffc(%ebp) 804834 d: leave 804834 e: ret 804834 f: nop . . . 0 xfff. . . INF 1060, Autumn 2007, Pål Halvorsen

Different Hardware University of Oslo Application program Operating System Application Operating System Hardware X Hardware Y INF 1060, Autumn 2007, Pål Halvorsen

Many Concurrent Tasks § Better utilization − many concurrent processes • performing different tasks • using different parts of the machine − many concurrent users § Challenges − − “concurrent” access protection/security fairness … University of Oslo Operating System Layer INF 1060, 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 INF 1060, 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 INF 1060, 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 INF 1060, Autumn 2007, Pål Halvorsen

History § OSes have evolved over the last 60 years § Early history (’ 40 s and early ’ 50 s): − first machines did not include OSes − programmed using mechanical switches or wires § Second generation (’ 50 s and ’ 60 s): − transistors introduced in mid-’ 50 s − batch systems − card readers University of Oslo INF 1060, Autumn 2007, Pål Halvorsen

History § Third generation (mid-’ 60 s to the ’ 80 s) − integrated circuits and simple multiprogramming − timesharing − graphical user interface − UNIX (’ 69 -’ 70) − BSD (’ 77) § Newer times (’ 80 s to present) − personal computers & workstations − MS-DOS (’ 82), Win (’ 85), Minix (’ 87), Linux (’ 91), Win 95, … University of Oslo INF 1060, 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 INF 1060, 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 INF 1060, 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: 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 INF 1060, 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 INF 1060, 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, x 11, xstart, …) University of Oslo INF 1060, Autumn 2007, Pål Halvorsen

Windows Interfaces The GUI incorporates a command line shell similar to the MS-DOS interface Applications access HW through the API consisting of a set of routines, protocols and other tools University of Oslo INF 1060, Autumn 2007, Pål Halvorsen

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) 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 INF 1060, Autumn 2007, Pål Halvorsen

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 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) int unsigned intfd) type, long int protocol) arg 2, unsigned long arg 3, sys_acct(const char sys_socketpair(int sys_chroot(const sys_sysctl(struct __sysctl_args char family, * 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, struct char __sysctl_args * sockaddr filename, *args) header, *umyaddr, int flags, cap_user_data_t 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_wait 4(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, timeval struct off_t sockaddr int offset, *tv, * stat_addr, struct unsigned *usockaddr, timezone intoptions) origin) *tz) int *usockaddr_len) sys_futex(void *uaddr, sys_getpeername(int sys_llseek(unsigned sys_adjtimex(struct timex 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 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 intint fd, *level, char buf, 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_getdents 64(unsigned sys_gettid(void) fd, structint msghdr pid, fd, struct void *msg, *sched_param dirent, 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, __old_kernel_stat policy) 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, int timespec bufsiz)*interval) sys_ni_syscall(void) sys_sync(void) sys_stat 64(char sys_setresuid(uid_t, * filename, uid_t); struct stat 64 * statbuf, long flags) sys_setpriority(int* which, sys_fsync(unsigned sys_lstat 64(char sys_setresgid(gid_t, filename, int gid_t, fd)intgid_t); struct who, int stat 64 niceval) * statbuf, long flags) sys_getpriority(int which, sys_fdatasync(unsigned sys_fstat 64(unsigned sys_setfsuid(uid_t); long intint fd, fd) who) struct stat 64 * statbuf, long flags) sys_reboot(intoption, sys_bdflush(int sys_sysfs(int sys_setfsgid(gid_t); magic 1, func, unsigned long int data) magic 2, long unsigned arg 1, unsigned int cmd, long void arg 2) * arg) sys_setregid(gid_t sys_getcwd(char sys_ustat(dev_t sys_chown 16(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_lchown 16(const 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_dup 2(unsigned sys_readahead(int sys_fchown 16(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_setregid 16(old_gid_t int long fildes) rgid, start, old_gid_t size_t len, egid) int flags) sys_setresuid(uid_tint sys_fcntl(unsigned sys_madvise(unsigned sys_setgid 16(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_fcntl 64(unsigned sys_mincore(unsigned sys_setreuid 16(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_setuid 16(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_setresuid 16(old_uid_t *rgid, fd, long unsigned gid_t ruid, 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_getresuid 16(old_uid_t flags) uid) int fd, unsigned *ruid, old_uid_t int cmd)*euid, old_uid_t *suid) sys_setfsgid(gid_tchar sys_mknod(const sys_munlockall(void) sys_setresgid 16(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_getresgid 16(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_setfsuid 16(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_setfsgid 16(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_getgroups 16(int gidsetsize, long * oldname, addr, old_gid_t const char *grouplist) * newname) sys_getsid(pid_t sys_link(const sys_swapoff(const sys_setgroups 16(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_getuid 16(void) specialfile, const int swap_flags) char * newname) sys_getgroups(int sys_umount(char sys_msgget sys_geteuid 16(void) (key_t*gidsetsize, key, name, intint msgflg) gid_t flags)*grouplist) sys_setgroups(int sys_oldumount(char sys_msgctl sys_getgid 16(void) (int msqid, gidsetsize, * name) int cmd, gid_t struct *grouplist) msqid_ds *buf) sys_newuname(struct sys_mount(char sys_msgsnd sys_getegid 16(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 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 statfs intintlen) mode) cmd, * buf) union semun arg) sys_getrlimit(unsigned sys_truncate(const sys_semop sys_chdir(const (int semid, char * 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, intmode_t unsigned resource, size, int mode) shmflg) long structlength) rlimit *rlim) sys_setrlimit(unsigned sys_truncate 64(const sys_shmctl sys_chmod(const (int shmid, char int * filename, resource, cmd, * path, struct mode_t loff_t struct shmid_ds length) rlimit mode) *rlim) *buf) sys_getrusage(int sys_ftruncate 64(unsigned sys_shmat sys_chown(const (int shmid, char who, char *struct filename, int *shmaddr, fd, rusage loff_t uid_t *ru) int length) 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) INF 1060, 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() INF 1060, 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 INF 1060, 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 University of Oslo INF 1060, 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 INF 1060, Autumn 2007, Pål Halvorsen

Interrupt Program Execution CPU University of Oslo INF 1060, 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 INF 1060, 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 INF 1060, 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) INF 1060, 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, L 4, Chorus, … University of Oslo INF 1060, 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 INF 1060, Autumn 2007, Pål Halvorsen