Booting Up & Processes

Transcription

1 CS 326: Operating Systems Booting Up & Processes Lecture 3

2 Today s Schedule Booting the System Process Structure Process Execution The Init System fork() wait() 1/31/18 CS 326: Operating Systems 2

3 Today s Schedule Booting the System Process Structure Process Execution The Init System fork() wait() 1/31/18 CS 326: Operating Systems 3

4 Booting Up When you turn on your computer, it starts the boot process Named for pulling oneself over a fence by one's bootstraps Or in other words, doing the impossible Booting is a series of tasks that ultimately get the operating system running The first thing you (may) see is the POST Power-on Self Test 1/31/18 CS 326: Operating Systems 4

5 1/31/18 CS 326: Operating Systems 5

6 BIOS After initializing the hardware, your basic inputoutput system (BIOS) will start iterating through the disks connected to your machine When installing a new OS, you may change the boot order On a Mac, you can do this by holding down Option during boot (other machines: F12, Del ) Once a bootable disk is found, we proceed to the next boot phase 1/31/18 CS 326: Operating Systems 6

7 Master Boot Record The first 512 bytes on a hard drive contain the Master Boot Record (MBR) The MBR has two parts: Partition table Partition: segment of a disk Partition 1: Windows; Partition 2: Linux; etc. Boot code Responsible for continuing the boot process 1/31/18 CS 326: Operating Systems 7

8 Finding a Bootable Partition 1. The BIOS looks for a disk partition that ends with 0x55AA 2. Then it moves to address 0x7C00 and begins executing the instructions there 1/31/18 CS 326: Operating Systems 8

9 Hard-Coded Offsets You might be surprised that these offsets are just hard-coded into the system However, the BIOS is not particularly smart To make it smart would begin to resemble an OS The hardware should be as simple as possible Making it smart is very expensive! The software (OS) does not want to make many assumptions about the underlying hardware 1/31/18 CS 326: Operating Systems 9

10 Continuing the Boot Process We began executing instructions, so we re all done starting the OS, right? Unfortunately, no The first instructions executed are part of the bootloader The bootloader is a bit smarter than the BIOS, and handles the next steps in the boot process 1/31/18 CS 326: Operating Systems 10

11 Bootloader The bootloader can understand a variety of file systems Invent a new file system? Add support to the bootloader. No need to modify the hardware ROM It can also provide a list of operating systems available in a multi-boot configuration And it can handle larger disks! The BIOS is limited to a fixed number of partitions and disk sizes 1/31/18 CS 326: Operating Systems 11

12 Bootloaders Linux: grub, grub2, syslinux Windows: NTLDR, BOOTMGR macos: BootX FreeBSD: boot0 1/31/18 CS 326: Operating Systems 12

13 Installing a Bootloader Folks with multi-boot Windows + Linux machines may have come across some wise advice: When multi-booting, always install Linux last! This is because the bootloader (often grub) gets installed on the disk s shared MBR Grub can boot Linux, Windows, FreeBSD, etc The Windows bootloader only knows of the existence of Windows Installing it last means you have no way to boot Linux! 1/31/18 CS 326: Operating Systems 13

14 Bootloader Restrictions You can only have one bootloader per disk Installing one will overwrite another Luckily, you can always insert another disk (rescue CD, USB, etc) The Raspberry Pi has a very limited bootloader Can only read FAT partitions Expects a fixed set of configuration files and OS data 1/31/18 CS 326: Operating Systems 14

15 Boot Stages The bootloader is split into two stages: Stage 1 Stage 2 (appropriately named!) Stage 1 contains basic initialization code and is limited to a fixed size Stage 2 adds file system support, basic menus, and can read from the disk 1/31/18 CS 326: Operating Systems 15

16 Linux Stage 2 In Linux, the second stage is represented by an initial ramdisk (initrd) This contains a lightweight, compressed Linux system image The initrd is mounted in memory and contains a limited set of tools (called early user space ) This environment (finally!) sets up the OS for use Hardware initialization, mounting file systems, etc. 1/31/18 CS 326: Operating Systems 16

17 Finishing the Boot Process Once the boot process is complete, the very first process takes over Process: a running instance of a program PID 1, also known as init, takes care of launching the rest of the OS System services, startup tasks, etc 1/31/18 CS 326: Operating Systems 17

18 A Note about EFI Modern systems have extensible firmware interface (EFI) instead of BIOS EFI adds a lot of nice features and is smarter than the traditional BIOS Once nice aspect of EFI is the bootloader is no longer required! However, most OS still use a bootloader for additional flexibility 1/31/18 CS 326: Operating Systems 18

19 Today s Schedule Booting the System Process Structure Process Execution The Init System fork() wait() 1/31/18 CS 326: Operating Systems 19

20 From Program to Process When a program is executed, the OS reads its static data from the disk and copies it into main memory Program instructions, string literals, binary data A process ID (PID) is assigned Space is allocated for the stack and heap File descriptors are initialized stdout, stderr, stdin Run-time permissions are applied 1/31/18 CS 326: Operating Systems 20

21 Process Memory Layout 1/31/18 CS 326: Operating Systems 21

22 Virtual Memory Processes are given a zeroed out virtual address space rather than accessing main memory directly Prevents viewing/changing other process data Makes memory allocation and management simpler A page table lets the OS allocate blocks of noncontiguous memory on demand The memory management unit (MMU) handles translating virtual à physical addresses Supported by most CPUs 1/31/18 CS 326: Operating Systems 22

23 Communication While processes aren t allowed to manipulate memory directly, they can create pools of shared memory for communication However, there are often simpler methods to communicate: Signals, sockets, pipes, or even files Higher-level inter-process communication (IPC) frameworks allow event-based messaging and remote procedure calls 1/31/18 CS 326: Operating Systems 23

24 Inspecting the System While processes are limited to virtualized views of the hardware, they are still able to inspect it Memory, CPU, disk availability and usage Other process names and command lines Logged in users Hardware specs, serial numbers, etc. This is good, especially in shared environments! Overall, processes are a low-level abstraction 1/31/18 CS 326: Operating Systems 24

25 Inspecting the System w 23:11:06 up 1 day, 7:57, 11 users, load average: 16.07, 15.17, USER TTY LOGIN@ IDLE JCPU PCPU WHAT mal pts/0 07:16 14:37m 0.07s 0.07s -bash zoe pts/1 20:04 3:06m 0.43s 0.38s vim output/file-0 wash pts/2 23:00 4: s 0.05s vim Makefile inara pts/3 21:52 1:08m 0.82s 0.79s /usr/bin/python2 jayne pts/4 23: s 0.03s 0.03s -bash malensek pts/5 23: s 0.10s 0.04s w 1/31/18 CS 326: Operating Systems 25

26 Today s Schedule Booting the System Process Structure Process Execution The Init System fork() wait() 1/31/18 CS 326: Operating Systems 26

27 Basic Unit of Execution: Process The process is one of the most fundamental parts of any operating system A running instance of a program In the early days, only one process could run at once After all, we only have one CPU, right? Multitasking challenged this idea: why not let multiple processes share the CPU? 1/31/18 CS 326: Operating Systems 27

28 Multitasking In early multitasking systems, processes were responsible for yielding control of the CPU to others Once you are given control of the CPU, you can do whatever you want! As you can imagine, no process wanted to give up control of the CPU Buggy processes can also take control of the CPU and never give it up 1/31/18 CS 326: Operating Systems 28

29 CPU Virtualization Putting processes in control was messy and error prone not to mention complicated! A better approach turned out to be virtualizing the CPU Making each process think it has exclusive control over its very own CPU This led to preemptive multitasking Processes can be preempted swapped out at will by the OS 1/31/18 CS 326: Operating Systems 29

30 Concurrent Tasks Let s assume you want to listen to music and work on your CS 326 homework If you only have a single core, you need to switch between these two tasks quickly Switch too slow, and your music will skip Switch quickly enough, and the user will think things are all happening at the same time! Hundreds of processes run per second 1/31/18 CS 326: Operating Systems 30

31 Multitasking > Interrupt Safari, save Safari state < Load KernelThread state, execute KernelThread > Interrupt KernelThread, save KernelThread state < Load cmatrix state, execute cmatrix > Interrupt cmatrix, save cmatrix state < Load vim state, execute vim > Interrupt vim, save vim state < Load KernelThread state, execute KernelThread > Interrupt KernelThread, save KernelThread state < Load Safari state > Interrupt Safari, save Safari state 1/31/18 CS 326: Operating Systems 31

32 State Information The previous example introduced some new terms: State information Interrupts State information is stored in Process Control Blocks (PCBs) This includes, variables, call stack, heap, etc. Only one active PCB per CPU As a program runs, the OS may interrupt it to pause its execution 1/31/18 CS 326: Operating Systems 32

33 Anatomy: Process Control Block (Isolated from other processes) Call Stack Heap Permissions, ownership Isolate file access Environment Variables Register States Stack pointer, program counter Memory Addressing 1/31/18 CS 326: Operating Systems 33

34 The Scheduler The OS scheduler is responsible for ensuring each process gets a share of the CPU Rather than letting processes coordinate this, the scheduler preempts them Context switch Each process can pretend it owns the CPU When a process is waiting for an I/O device, it gets switched out until the operation completes Interleaves I/O and CPU usage 1/31/18 CS 326: Operating Systems 34

35 Scheduling Algorithms The OS scheduler is responsible for: Deciding which process gets to run Execution duration Scheduling frequency Different scheduling algorithms have different priorities Round robin scheduling: basic, fair, but does it provide good interactive performance? 1/31/18 CS 326: Operating Systems 35

36 Process State Transitions 1/31/18 CS 326: Operating Systems 36

37 Today s Schedule Booting the System Process Structure Process Execution The Init System fork() wait() 1/31/18 CS 326: Operating Systems 37

38 The First Process: PID 1 The very first process in a UNIX-like OS is called init Direct or indirect ancestor of all other processes Init is responsible for starting services, launching applications, rebooting/shutting down the system Specific init implementation can do more or less: System V Init, systemd, upstart, launchd, etc. You can even write your own! Boot Linux with flag: init=/path/to/your/init 1/31/18 CS 326: Operating Systems 38

39 Linux: init/main.c /* We try each of these until one succeeds. * The Bourne shell can be used instead of init if we are * trying to recover a really broken machine. */ if (execute_command) { ret = run_init_process(execute_command); if (!ret) return 0; panic("requested init %s failed (error %d).", execute_command, ret); } if (!try_to_run_init_process("/sbin/init")!try_to_run_init_process("/etc/init")!try_to_run_init_process("/bin/init")!try_to_run_init_process("/bin/sh")) return 0; panic("no working init found. Try passing init= option to kernel. " "See Linux Documentation/admin-guide/init.rst for guidance."); 1/31/18 CS 326: Operating Systems 39

40 Process Lineage ps -ef UID PID PPID C STIME TTY TIME CMD root Feb21? 00:00:57 /usr/lib/systemd/systemd root Feb21? 00:00:00 [kthreadd] root Feb21? 00:00:00 [ksoftirqd/0] root Feb21? 00:00:00 [kworker/0:0h] root Feb21? 00:01:21 [rcu_sched] root Feb21? 00:00:00 [rcu_bh] root Feb21? 00:00:13 [rcuos/0] root Feb21? 00:00:00 [rcuob/0] root Feb21? 00:00:00 [migration/0] root Feb21? 00:00:00 [lru-add-drain] root Feb21? 00:00:01 [watchdog/0]... malensek Feb21 tty1 00:00:00 login -- malensek malensek Feb21 tty1 00:00:00 bash 1/31/18 CS 326: Operating Systems 40

41 Init Responsibilities Some init systems may do more than others, but at a basic level they are responsible for one key task: Launching other processes When one process launches another, it is that process s parent The newly-launched process is the child Unfortunately there are no uncle or aunt processes 1/31/18 CS 326: Operating Systems 41

42 Creating Processes On Unix systems, we create processes with the fork system call Fork creates a duplicate (clone) of a running process Once the call to fork() is complete, the two processes run independently, moving on to the next instruction We can distinguish between the parent and child using the return value of the fork call Child: zero; Parent: non-zero 1/31/18 CS 326: Operating Systems 42

43 fork() example pid_t child = fork(); if (child == 0) { /* I am the child */ printf("child\n"); } else if (child == -1) { /* Something went wrong */ perror("fork"); } else { /* I am the parent */ printf("parent\n"); } 1/31/18 CS 326: Operating Systems 43

44 Waiting for Children A good parent will make sure its children finish their work, but it s not a requirement To do this, we can use the wait() system call Wait will block the parent until the specified child PID completes execution Does the init system wait on its children? 1/31/18 CS 326: Operating Systems 44

45 wait() example pid_t child = fork();... /* Parent code */ pid_t my_pid = getpid(); printf("parent (PID %d) waiting for child (PID %d)!\n", my_pid, child); wait(&child); 1/31/18 CS 326: Operating Systems 45