INF 1060 Introduction to Operating Systems and Data

INF 1060: Introduction to Operating Systems and Data Communication Operating Systems: Introduction Pål Halvorsen 14/9 - 2005

Overview ü Basic execution environment – Intel example ü What is an operating system (OS)? ü Short history ü OS components and services (extended in later lectures) ü Booting ü Kernel organization INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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, …) INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 mouse, keyboard, parallel, serial, and USB connectors Video 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 Diskette connector IDE drive connectors INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

Intel 32 -bit Architecture (IA 32): Basic Execution Environment ü Address space: 1 – 236 (64 GB), each program may have a linear address space of 4 GB (2 32) ü Basic Ø 8 Ø 6 Ø 1 program execution registers: general purpose registers (EAX, EBX, ECX, EDX, ESI, EDI, EBP and ESP) segment registers (CS, DS, SS, ES, FS and GS) flag register (EFLAGS) instruction pointer register (EIP) PUSH %eax PUSH %ebx PUSH %ecx <do something> GPRs: EAX: EBX: ECX: EDX: X Y Z ESI: ü Stack – a continuous array of memory locations er h EDI: t POP %ecx eo Ø Current stack is referenced by the SS register h. EBP: t POP %ebx d ESP: see arrow e y Ø ESP register – stack pointer POP %eax STACK: pla s i d Ø EBP register – stack frame base pointer (fixed reference) en ESP … t f o Ø PUSH – stack grow, add item (ESP decrement) X ery Y v Ø POP – remove item, stack shrinks (ESP increment) is Z y!! a w 0 xfff. . . k e h ü Several other registers like Control, MMX, B! T c sta N monitoring XMM, FPU, MTRR, MSR and performance INF 1060 – introduction to operating systems and data communication 0 x 0. . . 2005 Kjell Åge Bringsrud & Pål Halvorsen

Intel 32 -bit Architecture (IA 32): Basic Execution Environment ü Example: main (void) { int a = 4, b = 2, c = 0; objdu c = a + b; mp -d } stack: code segment: … 8048314 <main>: push %ebp 8048315: mov %esp, %ebp 8048317: sub $0 x 18, %esp 804831 a: and $0 xfffffff 0, %esp $0 x 0, %eax 804831 c: mov 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 xfff. . . … . . . … 8048314: EAX: … 6 2 0 old EBP 4 2 6 0 Accumulator for operands and results data ESP: 0 xffffffd 0 0 xffffffd 8 0 xfffffff 4 0 xfffffff 0 add 24 bytes Stack pointer EBP: 0 xfffffff 0 ? ? ? add 8 bytes Pointer to data on stack EPI: … 8048342 8048314 8048315 804832 b 804831 a 8048324 8048339 8048317 8048322 8048332 804831 c 804833 f Pointer to next instruction to be executed 0 x 0. . . INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

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 Ø Ø ü 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) downward to allocate space for local variables When returning, a C function does Ø Ø ü push the parameters into stack in reverse order push return address (current EIP value) onto stack 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

C Function Calls & Stack ü Example: int add (int a, int b) { return a + b; } main (void) { int c = 0; c = add(4 , 2); } stack: ESP EBP 0 6 … objdu mp -d 1. 2. 3. Pop return instruction pointer into the EIP register Release parameters (ESP) Resume caller execution Note: this arrow now shows in this illustration the instruction to be executed, EIP shows next 1. 2. 0 xfff. . . code segment: 3. Push EIP register Loads the offset of the called procedure in the EIP register Begin execution 8048314 <add>: 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, 1) 804833 e: movl $0 x 4, (%esp, 1) 8048345: call 8048314 <add> 804834 a: mov %eax, 0 xfffffffc(%ebp) 804834 d: leave 804834 e: ret 804834 f: nop . . . … … 2 4 804834 a old EBP 0 x 0. . . INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

Different Hardware Application program Operating System Application Operating System Hardware X Hardware Y INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

Many Concurrent Tasks ü Better utilization Ø many concurrent processes n n Ø performing different tasks using different parts of the machine many concurrent users ü Challenges Ø Ø “concurrent” access protection/security fairness … Operating System Layer INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication user application operating system hardware 2005 Kjell Åge Bringsrud & Pål Halvorsen

Where do we find OSes? Computers Game Boxes Phones Cars INF 1060 – introduction to operating systems and data communication cameras, other vehicles/crafts, set-top boxes, watches, sensors, … 2005 Kjell Åge Bringsrud & 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. INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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, … INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 happends ü 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

Primary Components ü Apparent to user Ø Shell Ø File system Ø Device management ü Transparent Ø Processor management Ø Memory management Ø Communication services Application program layer Operating system layer User interface (shell) File management Device management Processor (or process) management Memory management Communication services Hardware layer INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication Note: this list of components is not complete. Some OSes have fewer, others more. Some have sub-components 2005 Kjell Åge Bringsrud & Pål Halvorsen

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!!? ? ) INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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) n n Ø 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, …) INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 (Win 16, Win 32, Win 64) INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

The Win. XP Desktop Interface Start button Taskbar INF 1060 – introduction to operating systems and data communication Notification area 2005 Kjell Åge Bringsrud & 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, …) INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

A Linux (KDE) Desktop Interface Desktop Application Starter Virtual Desktops Panel Taskbar INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

Typical (UNIX) Line Commands INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 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) 2005 Kjell Åge sys_shmget (key_t key, size_t size, Bringsrud int shmflag) & Pål Halvorsen user space kernel space OS components INF 1060 – introduction to operating systems and data communication

System Calls: read ü C example: count = read(fd, buffer, nbyte) 1. push parameters on stack read library procedure register 2. call library code X (read) count = read (fd , buffer , nbytes) memory (stack) 3. put system call number in register 4. call kernel (TRAP) ü ü ü 5. nbytes buffer fd buffer user space kernel examines system call number finds requested system call handler execute requested operation system call handler return to library and clean up ü ü 6. application increase instruction pointer remove parameters from stack resume process INF 1060 – introduction to operating systems and data communication X sys_read() 2005 Kjell Åge Bringsrud & 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 n n n read root file system and locate file with OS kernel load kernel into memory run kernel INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

Interrupt Program Execution CPU INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen

Interrupt (and Exception) Handling ü The IA-32 has a 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. user execute the interrupt handler 4. restore interrupted process 5. continue execution INF 1060 – introduction to operating systems and data communication kernel disk interrupt (x) IDT: Interrupt routines: 2005 Kjell Åge Bringsrud & Pål Halvorsen

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, … INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & 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 INF 1060 – introduction to operating systems and data communication 2005 Kjell Åge Bringsrud & Pål Halvorsen