Operating Systems Lecture Notes

Lecture 7
OS Potpourri
Martin C. Rinard
When does a process need to access OS functionality? Here are several examples
o Reading a file. The OS must perform the file system operations required to read
the data off of disk.
o reating a child process. The OS must set stuff up for the child process.
o Sending a packet out onto the net!ork. The OS typically handles the net!ork
interface.
Why have the OS do these things? Why doesn"t the process #ust do them directly?
o onvenience. $mplement the functionality once in the OS and encapsulate it
%ehind an interface that everyone uses. So& processes #ust deal !ith the simple
interface& and don"t have to !rite complicated lo!'level code to deal !ith devices.
o (orta%ility. OS exports a common interface typically availa%le on many hard!are
platforms. )pplications do not contain hard!are'specific code.
o (rotection. $f give applications complete access to disk or net!ork or !hatever&
they can corrupt data from other applications& either maliciously or %ecause of
%ugs. Having the OS do it eliminates security pro%lems %et!een applications. Of
course& applications still have to trust the OS.
Ho! do processes invoke OS functionality? *y making a system call. onceptually&
processes call a su%routine that goes off and performs the required functionality. *ut OS
must execute in a different protection domain than the application. Typically& OS executes
in supervisor mode& !hich allo!s it to do things like manipulate the disk directly.
To s!itch from normal user mode to supervisor mode& most machines provide a system
call instruction. This instruction causes an exception to take place. The hard!are s!itches
from user mode to supervisor mode and invokes the exception handler inside the
operating system. There is typically some kind of convention that the process uses to
interact !ith the OS.
+et"s do an example ' the Open system call. System calls typically start out !ith a normal
su%routine call. $n this case& !hen the process !ants to open a file& it #ust calls the Open
routine in a system li%rary someplace.
/* Open the Nachos file "name", and return an "OpenFileId" that can
* be used to read and write to the file.
*/
OpenFileId Open(char *name);
$nside the li%rary& the Open su%routine executes a sscall instruction& !hich generates a
system call exception.
Open!
addiu "#,"$,%&'Open
sscall
( ")*
.end Open
*y convention& the Open su%routine puts a num%er ,in this case %&'Open- into register ..
$nside the exception handler the OS looks at register . to figure out !hat system call it
should perform.
The Open system call also takes a parameter ' the address of the character string giving
the name of the file to open. *y convention& the compiler puts this parameter into register
/ !hen it generates the code that calls the Open routine in the li%rary. So& the OS looks in
that register to find the address of the name of the file to open.
0ore conventions1 succeeding parameters are put into register 2& register 3& etc. )ny
return values from the system call are put into register ..
$nside the exception handler& the OS figures out !hat action to take& performs the action&
then returns %ack to the user program.
There are other kinds of exceptions. 4or example& if the program attempts to deference a
56++ pointer& the hard!are !ill generate an exception. The OS !ill have to figure out
!hat kind of exception took place and handle it accordingly. )nother kind of exception is
a divide %y 7 fault.
Similar things happen on a interrupt. When an interrupt occurs& the hard!are puts the OS
into supervisor mode and invokes an interrupt handler. The difference %et!een interrupts
and exceptions is that interrupts are generated %y external events ,the disk $O completes&
a ne! character is typed at the console& etc.- !hile exceptions are generated %y a running
program.
O%#ect file formats. To run a process& the OS must load in an executa%le file from the disk
into memory. What does this file contain? The code to run& any initiali8ed data& and a
specification for ho! much space the uninitiali8ed data takes up. 0ay also %e other stuff
to help de%uggers run& etc.
The compiler& linker and OS must agree on a format for the executa%le file. 4or example&
5achos uses the follo!ing format for executa%les1
+define NOFF,-.I& $/badfad /* ma0ic number denotin0 Nachos
* ob(ect code file
*/
tpedef struct se0ment 1
int 2irtual-ddr; /* location of se0ment in 2irt addr
space */
int inFile-ddr; /* location of se0ment in this file */
int si3e; /* si3e of se0ment */
4 %e0ment;
tpedef struct noff5eader 1
int noff,a0ic; /* should be NOFF,-.I& */
%e0ment code; /* e/ecutable code se0ment */
%e0ment init6ata; /* initiali3ed data se0ment */
%e0ment uninit6ata; /* uninitiali3ed data se0ment 77
* should be 3ero8ed before use
*/
4 Noff5eader;
What does the OS do !hen it loads an executa%le in?
o Reads in the header part of the executa%le.
o hecks to see if the magic num%er matches.
o 4igures out ho! much space it needs to hold the process. This includes space for
the stack& the code& the initiali8ed data and the uninitiali8ed data.
o $f it needs to hold the entire process in physical memory& it goes off and finds the
physical memory it needs to hold the process.
o $t then reads the code segment in from the file to physical memory.
o $t then reads the initiali8ed data segment in from the file to physical memory.
o $t 8eros the stack and unintiali8ed memory.
Ho! does the operating system do $O? 4irst& !e give an overvie! of ho! the hard!are
does $O.
There are t!o %asic !ays to do $O ' memory mapped $O and programmed $O.
o 0emory mapped $O ' the control registers on the $O device are mapped into the
memory space of the processor. The processor controls the device %y performing
reads and !rites to the addresses that the $O device is mapped into.
o (rogrammed $O ' the processor has special $O instructions like $5 and O6T.
These control the $O device directly.
Writing the lo! level& complex code to control devices can %e a very tricky %usiness. So&
the OS encapsulates this code inside things called device drivers. There are several
standard interfaces that device drivers present to the kernel. $t is the #o% of the device
driver to implement its standard interface for its device. The rest of the OS can then use
this interface and doesn"t have to deal !ith complex $O code.
4or example& 6nix has a %lock device driver interface. )ll %lock device drivers support a
standard set of calls like open& close& read and !rite. The disk device driver& for example&
translates these calls into operations that read and !rite sectors on the disk.
Typically& $O takes place asynchronously !ith respect to the processor. So& the processor
!ill start an $O operation ,like !riting a disk sector-& then go off and do some other
processing. When the $O operation completes& it interrupts the processor. The processor is
typically vectored off to an interrupt handler& !hich takes !hatever action needs to take
place.
Here is ho! 5achos does $O. 9ach device presents an interface. 4or example& the disk
interface is in disk.h& and has operations to start a read and !rite request. When the
request completes& the :hard!are: invokes the Handle$nterrupt method.
Only one thread can use each device at a time. )lso& threads typically !ant to use devices
synchronously. So& for example& a thread !ill perform a disk operation then !ait until the
disk operation completes. 5achos therefore encapsulates the device interface inside a
higher level interface that provides synchronous& synchroni8ed access to the device. 4or
the disk device& this interface is in synchdisk.h. This provides operations to read and !rite
sectors& for example.
9ach method in the synchronous interface ensures exclusive access to the $O device %y
acquiring a lock %efore it performs any operation on the device.
When the synchronous method gets exclusive access to the device& it performs the
operation to start the $O. $t then uses a semaphore ,( operation- to %lock until the $O
operation completes. When the $O operation completes& it invokes an interrupt handler.
This handler performs a ; operation on the semaphore to un%lock the synchronous
method. The synchronous method then releases the lock and returns %ack to the calling
thread.