Скачать презентацию INF 1060 Introduction to Operating Systems and Data
3e389aca1912fec4cfbcb57e3809e823.ppt
- Количество слайдов: 35
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
Intel 32 -bit Architecture (IA 32): Basic Execution Environment code segment: § Example: … 8048314
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
Different Hardware Application program Operating System Application Operating System Hardware X University of Oslo Application program 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 User interface (shell) § Transparent − Processor management − Memory management − Communication services 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 for the user to create, delete, modify and manipulate files User Interface: Operating system layer Device Management: provide a mechanism for user and User interface application to communicate with 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 display, printer and disk like keyboard, 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, unsigned sys_fchdir(unsigned int fd) sys_socket(int char *name) int arg 2, unsigned long arg 3, sys_acct(const family, int type, longprotocol) sys_sysctl(struct family, int type, sys_chroot(const __sysctl_args sys_socketpair(intchar * filename) int sys_acct(const char * filename)*args) protocol, int usockvec[2]) sys_sysctl(struct __sysctl_args int flags, sys_open(const char * filename, *umyaddr, int addrlen) sys_bind(int fd, struct sockaddr header, int mode) sys_capget(cap_user_header_t *args) cap_user_data_t dataptr) ys_time(int * tloc) sys_creat(const int * pathname, int mode) sys_listen(int fd, charbacklog) sys_capset(cap_user_header_t header, const cap_user_data_t data) sys_stime(int tptr) sys_close(unsigned int fd) sys_accept(int*fd, struct sys_exit(int error_code) sockaddr *upeer_sockaddr, int *upeer_addrlen) sys_gettimeofday(struct timeval * *uservaddr, options, sys_vhangup(void) sys_connect(int pid, unsigned int *tv, struct timezone *tz) struct rusage * ru) sys_wait 4(pid_t fd, struct sockaddr stat_addr, intint addrlen) sys_settimeofday(struct *tv, struct timezone int sys_lseek(unsigned int fd, off_t offset, unsigned int origin) sys_getsockname(int fd, timevalint * stat_addr, int options) sys_waitpid(pid_t pid, unsigned sockaddr *usockaddr, *tz) *usockaddr_len) sys_adjtimex(struct int fd, unsigned long offset_high, sys_llseek(unsigned timex op, sockaddr *usockaddr, *utime) sys_getpeername(int fd, structint sys_futex(void *uaddr, int *txc_p)val, struct timespec int *usockaddr_len) sys_alarm(unsigned int seconds) sys_read(unsigned int * *info) sys_sendto(int fd, voidfd, char * buf, size_t count) sys_sysinfo(struct sysinfobuff, size_t len, unsigned flags, sys_getpid(void) sys_write(unsigned int buff, size_t len, *value) sys_send(int fd, which, struct itimervalunsigned flags) sys_getitimer(intvoid * fd, const char * buf, size_t count) sys_getppid(void) sys_readv(unsigned void * ubuf, size_t *value, sys_recvfrom(int fd, long fd, const struct iovec * vector, sys_setitimer(int which, struct itimerval size, unsigned flags, sys_getuid(void) sys_writev(unsigned long fd, const sys_recv(int fd, /* it's ubuf, size_t struct iovec * flags) sys_sync(void); void * really int */ size, unsigned vector, sys_geteuid(void) sys_pread(unsigned int fd, buf, * len) sys_setsockopt(int fd, int level, int optname, char *optval, int optlen) sys_syslog(int type, char * char intbuf, sys_getgid(void) sys_pwrite(unsigned int sys_getsockopt(int fd, int level, int optname, sys_nice(int increment) fd, const char * buf, char *optval, int *optlen) sys_getegid(void) sys_getdents(unsigned int fd, sys_shutdown(int fd, int how) pid, * dirent, sys_sched_setscheduler(pid_t void int policy, unsigned int count) sys_gettid(void) sys_getdents 64(unsigned pid, void sched_param *param) sys_sendmsg(int fd, struct * dirent, unsigned int sys_sched_setparam(pid_t msghdr *msg, unsigned flags) count) sys_nanosleep(struct timespec *rqtp, int nfds, long timeout) sys_poll(struct pollfd * ufds, unsignedstruct timespec flags) sys_recvmsg(int fd, struct msghdr sys_sched_getscheduler(pid_t pid) *msg, unsigned int *rmtp) sys_chown(const call, unsigned long sys_stat(char * filename, struct __old_kernel_stat * statbuf) sys_socketcall(int char *, uid_t, gid_t); sched_param *param) sys_sched_getparam(pid_t pid, struct*args) sys_lchown(const int action, struct statbuf) sys_newstat(char *, uid_t, gid_t); sys_tux (unsigned* filename, user_req_t *int len, sys_sched_setaffinity(pid_t pid, unsigned*u_info) sys_fchown(unsigned int, struct __old_kernel_stat sys_lstat(char * filename, uid_t, gid_t); sys_io_setup(unsigned nr_reqs, unsigned int len, * sys_sched_getaffinity(pid_t pid, aio_context_t *ctxp) statbuf) sys_setregid(gid_t, filename, struct sys_newlstat(char *gid_t); sys_io_destroy(aio_context_t ctx) stat * statbuf) sys_sched_yield(void) sys_setgid(gid_t); sys_fstat(unsigned int fd, struct policy) sys_io_submit(aio_context_t ctx_id, long nr, sys_sched_get_priority_max(int __old_kernel_stat * statbuf) sys_setreuid(uid_t, uid_t); sys_newfstat(unsigned int fd, struct stat sys_io_cancel(aio_context_t ctx_id, struct statbuf) sys_sched_get_priority_min(int policy) * iocb *iocb, sys_setuid(uid_t); sys_readlink(const char * path, pid, struct timespec sys_io_getevents(aio_context_t ctx_id, sys_sched_rr_get_interval(pid_tchar * buf, int bufsiz)*interval) sys_setresuid(uid_t, sys_stat 64(char sys_sync(void) * filename, struct sys_ni_syscall(void) uid_t, uid_t); stat 64 * statbuf, long flags) sys_setresgid(gid_t, sys_lstat 64(char * filename, who, sys_fsync(unsigned int fd) gid_t); stat 64 * statbuf, long flags) sys_setpriority(int which, int structint niceval) sys_setfsuid(uid_t); sys_fstat 64(unsigned long fd) sys_fdatasync(unsigned intfd, struct sys_getpriority(int which, int who) stat 64 * statbuf, long flags) sys_setfsgid(gid_t); sys_sysfs(int option, long magic 2, arg 1, unsigned long arg 2) sys_bdflush(int func, unsigned long unsigned int cmd, void * arg) sys_reboot(int magic 1, int data) sys_chown 16(const char * ustat * sys_ustat(dev_t *buf, gid_t egid) ubuf) sys_getcwd(chardev, struct filename, size) sys_setregid(gid_t rgid, unsigned longold_uid_t user, old_gid_t group) sys_lchown 16(const sys_sendfile(int char * int filename, old_uid_t user, count) sys_uselib(const gid)char * in_fd, sys_setgid(gid_tout_fd, library) off_t *offset, size_t old_gid_t group) sys_fchown 16(unsigned int offset, sys_readahead(int uid_t euid) size_t newfd) sys_dup 2(unsignedruid, oldfd, unsigned intcount) sys_setreuid(uid_t fd, loff_t fd, old_uid_t user, old_gid_t group) sys_setregid 16(old_gid_t start, size_t len, int sys_msync(unsigned sys_dup(unsigned int fildes) sys_setuid(uid_t uid) long rgid, old_gid_t egid) flags) sys_setgid 16(old_gid_t gid) sys_madvise(unsigned long start, size_t len, int sys_fcntl(unsigned ruid, unsigned uid_t suid) behavior) sys_setresuid(uid_tint fd, uid_t euid, int cmd, unsigned long arg) sys_setreuid 16(old_uid_t sys_mincore(unsigned longuid_t *euid, euid) sys_fcntl 64(unsigned int fd, start, size_tuid_t unsigned long arg) sys_getresuid(uid_t *ruid, old_uid_tlen, *suid) unsigned int cmd, sys_setuid 16(old_uid_t uid) sys_mlock(unsigned long start, size_t len) sys_nfsservctl(int cmd, void *argp, gid_t sgid) sys_setresgid(gid_t rgid, gid_t egid, void *resp) sys_setresuid 16(old_uid_t ruid, *egid, gid_t sys_munlock(unsigned long start, size_t len) *sgid) sys_ioctl(unsigned int fd, gid_t old_uid_t euid, old_uid_t suid) sys_getresgid(gid_t *rgid, unsigned int cmd, unsigned long arg) sys_getresuid 16(old_uid_t *ruid, old_uid_t *euid, old_uid_t *suid) sys_mlockall(int flags) sys_flock(unsigned int sys_setfsuid(uid_t uid) fd, unsigned int cmd) sys_setresgid 16(old_gid_t rgid, old_gid_t egid, old_gid_t sys_munlockall(void) sys_mknod(const gid) sys_setfsgid(gid_tchar * filename, int mode, dev_t dev) sgid) sys_getresgid 16(old_gid_t sys_brk(unsigned long pathname, int mode) sys_mkdir(const tms * tbuf) sys_times(struct char * brk)*rgid, old_gid_t *egid, old_gid_t *sgid) sys_setfsuid 16(old_uid_t uid) sys_munmap(unsigned long addr, sys_rmdir(const char pathname) sys_setpgid(pid_t pid, *pid_t pgid) size_t len) sys_setfsgid 16(old_gid_t sys_mprotect(unsigned gid) sys_unlink(const char pathname) sys_getpgid(pid_t pid)* long start, size_t len, unsigned long prot) sys_getgroups 16(int sys_mremap(unsigned * oldname, sys_symlink(const gidsetsize, old_gid_t *grouplist) sys_getpgrp(void) char long addr, const char * newname) sys_setgroups 16(int sys_swapoff(const * oldname, old_gid_t * newname) sys_link(const char * specialfile) sys_getsid(pid_t pid)gidsetsize, const char*grouplist) sys_getuid 16(void) sys_swapon(const sys_rename(const sys_setsid(void) char * oldname, const char * newname) specialfile, int swap_flags) sys_geteuid 16(void) sys_msgget (key_t name, msgflg) sys_umount(char gidsetsize, flags) sys_getgroups(int * key, intint gid_t *grouplist) sys_getgid 16(void) sys_msgctl (int msqid, int cmd, sys_oldumount(char * name) struct msqid_ds sys_setgroups(int gidsetsize, gid_t *grouplist) *buf) sys_getegid 16(void) sys_msgsnd (int msqid, struct msgbuf name) sys_mount(char * dev_name, char * dir_name, char msgsz, sys_newuname(struct new_utsname * *msgp, size_t * type, int msgflg) sys_utime(char msqid, struct int len) sys_msgrcv (int * filename, struct utimbuf * char *put_old) sys_pivot_root(const char *new_root, const times) sys_sethostname(char *name, msgbuf *msgp, size_t msgsz, sys_utimes(char * key, int nsems, statfs sys_semget (key_t filename, structint sys_statfs(const char * path, struct timeval**buf) sys_gethostname(char *name, int len)semflg) utimes) sys_access(const char int semnum, int * sys_semctl (int semid, * filename, int mode) sys_fstatfs(unsigned int fd, struct int len) buf) sys_setdomainname(char *name, statfscmd, union semun arg) sys_chdir(const char * int path, sys_semop (int semid, filename)unsigned rlimit *rlim) sys_truncate(const char * resource, *tsops, unsigned sys_getrlimit(unsigned struct sembufstruct long length) nsops) sys_fchmod(unsigned int fd, mode_t mode) sys_shmget (key_t key, size_t size, int shmflg) sys_ftruncate(unsigned int resource, struct rlimit sys_old_getrlimit(unsigned fd, unsigned long length) *rlim) sys_chmod(const char sys_shmctl (int shmid, * filename, mode_t mode) sys_truncate 64(const int cmd, struct shmid_ds *buf) sys_setrlimit(unsignedcharresource, struct rlimit *rlim) * path, loff_t length) sys_chown(const who, filename, uid_t user, sys_shmat (int shmid, *struct rusage *ru) sys_ftruncate 64(unsigned int fd, loff_t length)gid_t group) sys_getrusage(intchar *shmaddr, int shmflg, ulong *raddr) sys_lchown(const char sys_shmdt (char *shmaddr) sys_umask(int mask) * filename, uid_t user, gid_t group) sys_fchown(unsigned int fd, uid_t int semflg) sys_semget (key_t key, int nsems, user, 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