FAME Operating Systems 2012 David Picard contributors : Arnaud Revel, Mickaël Maillard picard@ensea.fr
1. Introduction A very simple computer Goals of an operating system Hardware management Task management OS families Features Multitasking, multiuser Architecture dependances Unix and Linux history
A very simple computer CPU Microprocessor
A very simple computer CPU Microprocessor Memory mem
A very simple computer CPU Hard disk keyboard Screen Microprocessor Memory Many peripherals mem others
mem CPU peripherals programs Memory : Programs
mem CPU peripherals programs data Memory : Programs Data
mem CPU peripherals programs data data, interactions Memory : Programs Data Peripherals : Data Interactions (high priority data)
Programs int main(int argc char ** argv) { int a, b, c ; float *A, *B ; /* check input */ if(argc < 3) { printf("usage : dotprod <a> <b>\n") ; return 1 ; } /* read a from args */ a = atoi(argv[1]); b = atoi(argv[2]) ;... Instructions Data
Programs int main(int argc char ** argv) { int a, b, c ; float *A, *B ; /* check input */ if(argc < 3) { printf("usage : dotprod <a> <b>\n") ; return 1 ; } /* read a from args */ a = atoi(argv[1]); b = atoi(argv[2]) ; Memory data instructions... instructions data
Running a program EIP CPU Read instruction from mem at adress contained in EIP register 0xAD00 : instruction 1 0x1D04 : instruction 2 0xAD08 : instruction 3 0xAD0C : instruction 4... mem
Running a program EIP CPU 0xAD00 : instruction 1 0x1D04 : instruction 2 0xAD08 : instruction 3 0xAD0C : instruction 4... Read instruction from mem at adress contained in EIP register Execution mem
Running a program EIP++ CPU 0xAD00 : instruction 1 0x1D04 : instruction 2 0xAD08 : instruction 3 0xAD0C : instruction 4... Read instruction from mem at adress contained in EIP register Execution EIP Incrementation mem
Running a program EIP CPU 0xAD00 : instruction 1 0x1D04 : instruction 2 0xAD08 : instruction 3 0xAD0C : instruction 4... Read instruction from mem at adress contained in EIP register Execution EIP Incrementation Next cycle mem
Interaction between programs, memory and peripherals Memory: Peripherals: Read data Write data Read data (e.g. Keyboard) Run instructions depending on data in memory Run other program contained in memory... Write data (e.g. Screen) Run instruction in case of interaction (e.g. power off buton)...
Goals of an OS Manage programs Start, stop, running, etc Integrity, security Communication between programs Manage memory Allocation Permissions, security Manage hardware Interface layer between programs and hardware Handle hardware event (ex: interrupt signals)
Managing Hardware Accessing hardware Programs may want to access to the leys pressed on a keyboard, or write some characters on the screen, etc The OS acts as an interface between programs and peripherals It translates the query of programs into commands to peripherals Simplicity gain for the programs, since the interface to different peripherals is unique
Managing hardware Interrupts Some peripherals may want to change the way programs are running (think to the stop button of an assembly chain) The OS must handle signal coming from peripherals
Managing hardware Critical sections The OS manages how requests to peripherals are handled and scheduled For instance, 2 programs printing a file should not end with an entanglement of text coming out of the printer
Managing Tasks Context When a taks is running, the OS manages its context (stack pointer, instruction pointer, loading libraries into memory, etc)
Managing Tasks Context switch Most OS can handle several programs running at the same time. They manage the contexts of each program and handle the switches from one task to another Security is also a big deal when running several programs (restrict permission of one task to read/write memory zones of others for example)
Managing Tasks Communication between programs Some programs must interact (exchange data, wait for termination, etc) OS handle how communication between programs is done (called IPC Inter Processus Communication)
OS Anatomy applications libc toolkit Operating System Task management Memory Management Hardware Management kernel hardware
OS families By use : Desktop: reactivity, many different programms, low constraints Real time: predictability, few known programs, strict constraints Embedded: very few known programs, very constrained (limited mem, etc)
Kernel types kernel : Monolithic : everything is in the kernel, device drivers, mem management, network protocoles, IPC, etc. (ex Linux, Solaris) Microkernel : basic are done by the kernel (task management, complex IPC). Other things are done by programs (device drivers, memory management, etc). (ex Mach, L4)
Comparison ÉCOLE NATIONALE SUPÉRIEURE DE L'ÉLECTRONIQUE ET DE SES APPLICATIONS
Modular kernels Monolithic, but Possibility to add/remove fonctionality while running (device driver for ex) Smaller (only necessary stuff is running) Less safe (need to validate all drivers that will be loaded) Ex : Linux
Common features Multitasking: Several programs can run at the same time Multi-user: Several users can use the OS at the same time Multi-architecture: Wide variety of architectures running the system
Multitasking Several tasks at the same time: Handle creation and destruction Handle access to resources Scheduling Critical resources Integrity (permission, rights and so on)
Multi-user Several users on the system: Handle critical resources Integrity of users data Handle communication between users
Multi-arch Different hardware configuration Independence of programs to the architecture (e.g. POSIX norm,...) Being able to run on several different arch (e.g. power, x86, arm, sparc,...)
History 69 : Thomson et Ritchie First version of UNIX PDP7/9; kernel 16Ko; Process 8Ko, Files 64Ko 72 : Kernighan et Ritchie : C programing language 73 : UNIX rewritten in C Process management File management Generic I/O
History 75 : first porting of UNIX 76 : 8/16 bits microprocessors 77 : Thomson at Berkeley Univ 500 installations 79 : Porting to VAX and IBM 82 : Sell by ATT Unix-based and Unix-like (100 000 install.)
History 84 : Normalization DEC (Ultrix) Gould (UTX) HP (HP-UX) 85 : MINIX by A. Tanenbaum 88 : standard desktop system SUN/BULL/IBM
History 89 : first free BSD Sep 91 : Linux 0.01 (inspired by Minix) Oct 91 : Linux 0.03 (bash and gcc) Dec 91 : Linux 0.10 (first external contrib) Jan 92 : Linux 0.12 (virtual mem, GPL licenced) Mar 92 : linux 0.95 (init/login, X)
History 93 : NetBSD and FreeBSD Mar 94 : Linux 1.0 (production stable, features comparable to UNIX) Mar 95 : Linux 1.2 (several architectures, modules) Jul 96 : Linux 2.0 (smp, Tux) Jan 99 : Linux 2.2
History 99 : MacOSX (hybrid kernel) 01 : Linux 2.4 03 : Linux 2.6 (preemptible kernel) 07 : Linux 2.6.23 (CFS scheduler) 08 : Linux 2.6.26 (Kgdb) 21 Jul 2011 : Linux 3.0.0 (13M lines of code)
Linux features Monolithic kernel Modules : functionality can be added or removed (only SVR4.2 and Solaris can do this) Kernel threads : some kernel features are independent Native multithreading Preemptible kernel: a process can be interrupted in kernel mode Multi-CPU support Many filesystems Many supported arch Small Performant Libre (free as in free speech)
Distributions Complete OS based on Linux kernel: Linux kernel C library and compiler (mostly gcc) Bootloader (grub, lilo,...) Init system to start the system (networking, printing, user interfaces, ) Shell (bash, dash, ksh, ) Package manager (apt, rpm, portage, ) Package repository loaded with verified programs
Distribution families Deb: Debian, ubuntu, and derived *.deb packages Debian : server, Ubuntu : desktop RPM: RedHat, SuSE, Mandriva, and derived *.rpm packages RedHat : server, Mandriva : desktop Slackware The Great Old One (paquets *.tgz) Sources based: gentoo, sourcemage,... Compile all software from sources Gentoo : portage package manager probably the best ever
Fundamental concepts Execution modes (hardware feature) User mode: instructions of the running program Reserved memory zone Specific context (stack pointeur, eip,...) Restricted permissions Kernel mode (supervisor): instruction of the kernel All memory zones Specific context All permission Accessed by interrupt (either software or hardware)
Fundamental features Process: instance of a running program and its associated context Files: everything is files, devices, documents, etc Permissions: files have different permission levels (user, group, other) Reentrant: several processes can be in kernel mode at the same time (check your local variable!)
User/Kernel Mode Using the computer is divided into 2 execution modes: kernel mode user mode User mode is for user programs root Services (printing, web server,...) Real users (mail, office, games, devel, ) Kernel mode is for... kernel programs
Modes and permissions Memory is restricted to modes User mode applications cannot access to Kernel memory zones Memory zones of other applications Most peripherals To handle permission, most processors have execution modes A restricted mode corresponding to user mode An administrator mode corresponding to kernel mode (or supervisor,...)
Acess to kernel mode Memory zones of the kernel are accessible only in supervisor Not accessible in user mode Access by an interrupt System switch to supervisor mode Kernel handles interrupt Back to user mode and continue user application
Switch to kernel mode Accessing kernel mode is done By hardware interrupts Switch to supervisor mode and execution of interrupt procedures When errors occurs System raises an exception, switch to supervisor mode and execution of exception procedures When programs ask services to the kernel by a System Call Software interrupt raised by an application Switch to supervisor mode and execution of procedures attached to the system call
Interruptions Signal raised by A peripheral Occurs at any time Procedure handling these are called drivers Processor instruction (soft interrupt) Special instruction allowing to switch to supervisor Procedures related to interruptions are initialized at system boot Part of kernel code
Exceptions Processor responses to incorrect instructions Interrupt raised by the processor Signals errors in the running procedure (permission fault for example) Allow the kernel to handle errors For example, allocate demanded resources (program asking for a non-allocated memory zone,...)
Interrupt handling When an interrupt occurs, the processor execute a procedure initialized at boot time User mode Program 1 System Program 1 call Clock interrupt Program 2 Kernel mode Kernel proc Interrupt return Kernel proc Interrupt return
System calls Are function that: Are called in user mode Are executed in supervisor Return in user mode (in the calling program) The system call is asked by a unique software interruption (0x80) Does the switch to supervisor System calls are identified by numbers The number of the system call is loaded in a register A table allows to know which procedure to call depending on the number present in the register
Linux 0.01 System calls are available in glibc #define _syscall0(type,name) \ type name(void) \ { \ type res; \ asm volatile ("int $0x80" \ : "=a" ( res) \ : "0" ( NR_##name)); \ if ( res >= 0) \ return res; \ errno = res; \ return 1; \ }
Kernel control path kernel control path is the sequence of instruction executed by the interrupt procedure Several kernel control path can be entangled Ex: a process asks for a non available resource, another process is executed and asks for a resource also An interrupt is raised during a kcp Need for a reentrant kernel