Operating Systems Design and Implementation Chapter 01 (version - - PDF document

Operating Systems

Design and Implementation

Chapter 01

(version January 30, 2008)

Melanie Rieback

Vrije Universiteit Amsterdam, Faculty of Sciences

• Dept. Computer Science

Room R4.23. Tel: (020) 598 7874 E-mail: melanie@cs.vu.nl, URL: www.cs.vu.nl/∼melanie/

01 Introduction 02 Processes 03 Input/Output 04 Memory Management 05 File Systems

00 – 1 /

Overview

• What’s an operating system?
• Concepts
• System calls
• Structure

01 – 1 Introduction/

Position Operating System

Banking system Airline reservation Operating system Web browser Compilers Editors Application programs Hardware System programs Command interpreter Machine language Microarchitecture Physical devices

Question: What distinguishes compilers, editors, etc. from operating systems?

01 – 2 Introduction/1.1 What is an Operating System

Abstraction over Hardware (1/2)

#define FDC_STATUS 0x3F4 /* status register */ #define FDC_DATA 0x3F5 /* data register */ #define MASTER 0x80 /* value: master? */ #define DIRECTION 0x40 /* value: R/W? */ PRIVATE void fdc_out(val) int val; { struct milli_state ms; if (need_reset) return; milli_start(&ms); while ((in_byte(FDC_STATUS) & (MASTER | DIRECTION)) != (MASTER | 0)) { if (milli_elapsed(&ms) >= TIMEOUT) { /* Controller is not listening. Hit it over the head. */ need_reset = TRUE; return; } }

• ut_byte(FDC_DATA, val);

} 01 – 3 Introduction/1.1 What is an Operating System

Abstraction over Hardware (2/2)

PRIVATE int

struct floppy *fp; /* pointer to the drive struct */ struct trans *tp; /* pointer to the transfer struct */ { int r, s; ... if(...){ fdc_out(f_opcode == DEV_WRITE ? FDC_WRITE : FDC_READ); fdc_out((fp->fl_head << 2) | f_drive); fdc_out(fp->fl_cylinder); fdc_out(fp->fl_head); fdc_out(fp->fl_sector); fdc_out(SECTOR_SIZE_CODE); fdc_out(f_sectors); fdc_out(gap[d]); /* sector gap */ fdc_out(DTL); /* data length */ } /* Get controller status and check for errors. */ r = fdc_results(); /* Compare actual numbers of sectors transferred with expected number. */ s = (f_results[ST_CYL] - fp->fl_cylinder) * NR_HEADS * f_sectors; s += (f_results[ST_HEAD] - fp->fl_head) * f_sectors; s += (f_results[ST_SEC] - fp->fl_sector); if ((s << SECTOR_SHIFT) != tp->tr_count) return(ERR_TRANSFER); /* This sector is next for I/O: */ fp->fl_sector = f_results[ST_SEC]; return(OK); } 01 – 4 Introduction/1.1 What is an Operating System

Views on Operating Systems

Idea: Operating system can be seen as: (1) virtual machine, extending the hardware functionality, or (2) bunch

• f software that manages the hardware resources.

Virtual machine:

• hide all the messy details of programming the hard-

ware.

• construct layers of software that provide more and

more functionality (f transfer() over fdc out()). Resource manager:

• software protects against simultaneous accesses

and usage of resources (one user of the floppy disk at a time)

• fair share of the resources (scheduling)
• account for using resources.

01 – 5 Introduction/1.1 What is an Operating System

How to View an Operating System

Basics: An operating system appears to applications and users as a library of functions ⇒ system calls. A group of system calls stand for a service that the

• perating system has to offer. In MINIX there are ba-

sically two groups:

• System calls related to managing files.
• System calls related to managing processes.

Primitive model: a process represents a user or ap- plication and executes a program on behalf of its owner. Data involved in this processing is retrieved from and stored on files. Data in files persist over processes.

01 – 6 Introduction/1.3 Operating System Concepts

Processes

Problem: the execution of a program requires the al- location of resources (CPU, disks, etc) needed by that

• program. We therefore need to keep track of these al-

locations. Model: however, a program is just a series of instruc- tions: you can’t allocate anything to that. Instead, we construct a representant for that program during its execution ⇒ process. A process is an invention by an operating system: it is used as a placeholder for executing programs so that we can keep a precise account of how program exe- cution is affecting the use of hardware and software resources.

process = program in execution

01 – 7 Introduction/1.3 Operating System Concepts

Multiple Processes

Idea: An operating system can support more than one process at a time: processes can be suspended and (re)activated. Problem: how do we get multiple processes ⇒ allow a process to create another process. Example: When you’re sitting at the terminal, a small program called a command shell is executed (yes, by means of a process). Suppose you issue the com- mand:

some_program

Then a process is created for the execution of some program:

A B D E F C

01 – 8 Introduction/1.3 Operating System Concepts

Files (1/2)

Problem: We need to have a means for storing and retrieving data associated with a program, indepen- dent of whether a process is executing that program. Model: A file is an abstraction of a real storage device (e.g. disk): you can read/write data from/to a file by providing (1) a position in that file, and (2) the amount

• f data to transfer.

Organization: a file is contained in a directory. A directory holds an identifier for each file it contains. These identifiers need to be stored as well ⇒ a direc- tory is a file.

01 – 9 Introduction/1.3 Operating System Concepts

Files (1/2)

Root directory Students Faculty Leo

• Prof. Brown

Files Courses CS101 CS105 Papers Grants SOSP COST-11 Committees

• Prof. Green
• Prof. White

Matty Robbert

01 – 10 Introduction/1.3 Operating System Concepts

Files – Concepts (1/2)

• Files are organized hierarchically, the top is called

root directory.

• Files are referenced through a pathname: a con-

catenation of directory names, ending with the filename: – an absolute pathname starts at the root direc- tory, for example: /home/steen/edu/os/chp.01/sheets.tex – a relative pathname starts at the current work- ing directory. Assume that the working direc- tory is /home/steen/edu. Same file as above:

• s/chp.01/sheets.tex

01 – 11 Introduction/1.3 Operating System Concepts

Files – Concepts (2/2)

• Files are protected:

– Each file can be accessed by (1) its owner, (2) a group member, or (3) everyone else. – Each file allows access for reading (r), writing (w), or execution (x).

• rwxr-x--x steen infstaff 144649 Aug 23 doit

Question: What does everyone else actually mean?

01 – 12 Introduction/1.3 Operating System Concepts

File System Mounting (1/2)

File systems are mapped onto real storage devices ⇒ a storage device may contain a file system. Problem: suppose you have several storage devices (USB sticks, hard disks, CD-ROM, etc.), each cur- rently containing a file system. How do you refer to them? In Windows: use a drive specification: D:\edu\bs\coll01\sheets.tex Note: Windows NTFS supports mounting as well.

01 – 13 Introduction/1.3 Operating System Concepts

File System Mounting (2/2)

In UNIX-like systems: mount a filesystem:

• Each real storage device is known to the operat-

ing system.

• A file system on storage device DEV can be at-

tached to the root file system.

• A mounted file system appears as a directory in

the root file system ⇒ the actual device is trans- parent.

mount -t iso9660 /dev/hdc /cdrom

Root Drive 0 a b c d c d a b x y x y (a) (b)

01 – 14 Introduction/1.3 Operating System Concepts

Special Files (1/2)

Idea: If storage devices can contain a file system, this means they can store bytes. Couldn’t we just read, say, the kth byte from a device regardless of the file system it contains? Model: Represent real storage devices through spe- cial files:

• block special files: all operations are performed

in units of blocks of bytes. Examples: hard disk, floppy disk, tapes.

• character special files: all operations are per-

formed in units of bytes. Examples: terminals, network interfaces, line printer. Note: special files are actually used as an abstraction

• ver all peripheral devices, not just those for storing

data.

01 – 15 Introduction/1.3 Operating System Concepts

Special Files (2/2)

Associated with each special file:

• major device number: denotes a class of similar

devices.

• minor device number: denotes a particular (real)

device.

brw-r----- 1 root disk 3, 1 Jan 22 14:07 hda1 brw-r----- 1 root disk 3, 2 Jan 22 14:07 hda2 brw-r----- 1 root disk 3, 3 Jan 22 14:07 hda3 brw-r----- 1 root disk 3, 4 Jan 22 14:07 hda4 brw-r----- 1 root disk 3, 5 Jan 22 14:07 hda5 crw-rw---- 1 root lp 99, 0 Jan 22 14:07 parport0 crw-rw---- 1 root lp 99, 1 Jan 22 14:07 parport1 crw-rw---- 1 root lp 99, 2 Jan 22 14:07 parport2 crw-rw---- 1 root lp 99, 3 Jan 22 14:07 parport3

01 – 16 Introduction/1.3 Operating System Concepts

System Calls Process Management (1/2)

Example: consider a very simple command shell:

• Wait for a user to type in a command, possibly

with some parameters. The command should cor- respond with a program name (i.e. executable file).

• Start a process that executes the program, i.e.

loads the specified file into memory, and starts executing it.

• Wait until the child process has finished.

01 – 17 Introduction/1.4 System Calls

System Calls Process Management (2/2)

Needed: (1) process creation, (2) have process exe- cute a file, (3) have a process wait for a child to finish.

while(TRUE){ read_command(command, parameters); pid = fork(); if( pid != 0 ){ /* parent process */ waitpid( pid, &status, 0 ); } else{ /* child process */ execve(command, parameters, 0); exit(0); } }

Question: Does it make sense to call exit(0)?

01 – 18 Introduction/1.4 System Calls

System Calls – Signals

Model: Processes sometimes need to be interrupted during their execution:

• Have some process send a signal to the process

that needs to be interrupted,

• An interrupted process can catch a signal by in-

stalling a handler.

int handler(){ printf("Going down...\n"); exit(0); } main(){ signal(SIGALRM, handler); alarm(60); while(TRUE) printf("."); }

Question: Who’s sending the signal SIGALRM? Question: What happens if we remove exit(0)?

01 – 19 Introduction/1.4 System Calls

System Calls – Files

• ✺✛✻✦✼✙✽★✾ : create a regular file, or possibly reinitialize

an existing one.

• ✿✮❀★❁❃❂★❄ : create a special file (can only be done by

superuser).

• ❂✴❅✮✼✓❁ : open a file for reading or writing, returns a

file descriptor.

• ✺✦❆★❂✷❇✛✼ : close an opened file.
• ✻✦✼✙✽✑❄ ,

file.

• ❆✙❇✛✼✙✼★❀ : set the file pointer to a specified position.

Question: Aren’t we missing something here?

01 – 20 Introduction/1.4 System Calls

System Calls – Directories

• ❆✦❉❊❁✷❀ : create a hard link to another file - appears

as just another file, but is actually just a pointer.

• ❋✙❁●❆✦❉❊❁✷❀ : remove a (hard) link to a file. As long as

there are links to a file, the file remains. Other- wise, it is removed permanently. Question: How do we remove files?

01 – 21 Introduction/1.4 System Calls

System Calls – Example (1/2)

Basic idea: We want to set up a small system for letting two processes exchange information across a pipe:

Process Pipe Process A B

• Pipes are implemented using file mechanisms;
• ne process writes data to the file, the other reads

from the file.

• Normally, processes read data from standard in-

put (console), and write data to standard output (console). We need to redirect standard I/O to

• ur pipe system.
• Files have filedescriptors; 0 is used for standard

input, 1 for standard output.

• Solution: use dup(fd) which returns the lowest-

available file descriptor, and associates it with the same file as identified by fd.

01 – 22 Introduction/1.4 System Calls

System Calls – Example (2/2)

#define STD_INPUT #define STD_OUTPUT 1 void pipeline(char* process1, char* process2) { int fd[2]; /* array to hold two file descriptors */ pipe(fd); /* create a pipe fd[1] → fd[0] */ if( fork() != 0 ){ /* parent */ close(fd[0]); /* no need to read from pipe */ close(STD_OUTPUT); /* prepare new std_output */ dup(fd[1]); /* assign std_out to fd[1] */ close(fd[1]); /* fd[1] no longer needed */ execl(process1, process1, 0); } else{ /* child */ close(fd[1]); /* no need to write to pipe */ close(STD_INPUT); /* prepare new std_input */ dup(fd[0]); /* assign std_in to fd[0] */ close(fd[0]); /* fd[0] no longer needed */ execl(process2, process2, 0); } }

01 – 23 Introduction/1.4 System Calls

OS Structure: Monolithic (1/2)

Return to caller 4 10 6 9 7 8 3 2 1 11 Dispatch Sys call handler Address 0xFFFFFFFF User space Kernel space (Operating system) Library procedure read User program calling read Trap to the kernel Put code for read in register Increment SP Call read Push fd Push &buffer Push nbytes 5

1-4: Prepare, and call library routine read(fd,buffer,nbytes). 5-6: Prepare, and switch to kernel 7-9: Lookup & sys. handler, and return to user mode 10-11: Return to program and pop the stack

01 – 24 Introduction/1.5 Operating System Structure

OS Structure: Monolithic (2/2)

Main procedure Service procedures Utility procedures

• User programs form a top layer of programs that

can call OS service procedures through system calls

• Middle layer is collection of programs implement-

ing system calls

• Lowest layer is collection of (small) utility programs

that are used to implement service procedures

01 – 25 Introduction/1.5 Operating System Structure

Virtual Machine

Basic idea: Provide a bare-bones layer on top of the hardware and build different operating systems on top

• f that. Essentially implement the OS system call in-

terface for different OSes.

I/O instructions here Trap here Trap here System calls here Virtual 370s CMS CMS CMS VM/370 370 Bare hardware

• Windows emulation under Linux (VMware)
• Linux emulation under Windows (VMware)
• FreeBSD emulation under Linux (Xen -

paravirtualization, meaning that the underlying sys- tem is not completely emulated for performance reasons)

01 – 26 Introduction/1.5 Operating System Structure

Client/Server System

Simple model: Organize all services procedures as programs that are run in separate processes (i.e., out- side the OS kernel). Service calls are translated to procedure calls that need to go through the OS ker- nel.

Client process Client process Process server

• Terminal

server

• File

server

• Memory

server

• Microkernel

User mode Kernel mode Client obtains service by sending messages to server processes Machine 1 Machine 2 Machine 3 Machine 4 Client Kernel File server Kernel Process server Kernel Terminal server Kernel Message from client to server Network

Question: What’s the big advantage here?

01 – 27 Introduction/1.5 Operating System Structure