%\documentclass[colorBG,slideColor,troispoints,pdf]{prosper} \documentclass[total,pdf]{prosper} %\documentclass[colorBG,slideColor,ps]{prosper} \usepackage[toc,highlight,Tycja]{HA-prosper} \usepackage{alltt,key,xr,cols,rcs,acro,nick,% graphicx,varioref,explanation,booktabs,multicol,textcomp,amstext} \usepackage[nolineno,noindent]{lgrind} %\definecolor{green}{rgb}{0,1,0} \RCS $Revision: 1.3 $ \renewcommand*{\bs}{\texttt{\char '134}} % Backslash `\' %\newcommand*{\labTitle}{LDAP Directories}1 \newcommand*{\subject}{Operating Systems and Systems Integration} \newcommand*{\emphcolour}[1]{\emph{\red#1}} \providecommand*{\RPM}{\acro{RPM}\xspace} \providecommand*{\CD}{\acro{CD}\xspace} \providecommand*{\IPC}{\acro{IPC}\xspace} \providecommand*{\UID}{\acro{UID}\xspace} \providecommand*{\GID}{\acro{GID}\xspace} \providecommand*{\SMP}{\acro{SMP}\xspace} \providecommand*{\API}{\acro{API}\xspace} \providecommand*{\OK}{\acro{OK}\xspace} \providecommand*{\IETF}{\acro{OK}\xspace} \providecommand*{\MS}{\acro{MS}\xspace} \providecommand*{\LILO}{\acro{LILO}\xspace} \providecommand*{\HCI}{\acro{HCI}\xspace} \providecommand*{\KDE}{\acro{KDE}\xspace} \providecommand*{\MBR}{\acro{MBR}\xspace} \providecommand*{\BSD}{\acro{BSD}\xspace} \providecommand*{\MB}{\acro{MB}\xspace} \providecommand*{\XP}{\acro{XP}\xspace} \providecommand*{\HAL}{\acro{HAL}\xspace} \providecommand*{\DLL}{\acro{DLL}\xspace} \providecommand*{\QNX}{\acro{QNX}\xspace} % Get rid of that horrible hash mark in slide numbers in ppr-prv.cls: \def\no{} \title{\mbox{}\blue{}Operating System}% \subtitle{Kernel and the boot process} \author{Nick Urbanik \texttt{}\\ \footnotesize{}Copyright Conditions: GNU FDL (see \url{http://www.gnu.org/licenses/fdl.html})\\% \institution{Department of Information and Communications Technology}}% \slideCaption{OSSI --- Operating System Kernel and Booting --- ver. \RCSRevision} \Logo{\includegraphics[width=15mm]{ict-logo-smaller}} \DefaultTransition{Wipe} \TitleSlideNav{FullScreen} \NormalSlideNav{ShowBookmarks} \LeftFoot{OSSI --- ver. \RCSRevision} \RightFoot{Operating System Kernel and Booting} \begin{document} \maketitle \begin{slide}{Operating System: Kernel and boot process} \vspace*{0.1\slideWidth} \begin{center}\Large \mbox{}\blue{}What is it? \vspace*{0.05\slideWidth} \mbox{}\blue{}What does it do? \vspace*{0.05\slideWidth} \mbox{}\blue{}How does it start up? \end{center} \end{slide} \tsection{Role of OS} \begin{slide}{What is an operating system?} \begin{itemize} \item Is it what you get when you install Linux, Windows \acro{XP} or Windows 2000? \item Does it include such things as (g)notepad, g++ or Visual C++? \item How about \texttt{bash}, \texttt{cmd.exe} or \texttt{command.com}? \end{itemize} \end{slide} \begin{slide}[bm=The OS is the kernel]{The \OS is the kernel} \begin{itemize} \item The {\blue{}operating system is the kernel} \item When the computer boots the operating system, it loads the kernel into memory. \end{itemize} \end{slide} \begin{slide}{Kernel in Linux} \begin{itemize} \item In Linux, kernel can be loaded by \LILO or \texttt{grub} \item Kernel is in \texttt{/boot} \item In RH 9, it is \begin{itemize} \item \texttt{/boot/vmlinuz-2.4.20-20.9}, \item or if you build your own, something like \texttt{/boot/vmlinuz-2.4.22-ac6} \end{itemize} \item It is a \emphcolour{monolithic kernel} \end{itemize} \end{slide} \begin{slide}[bm=Kernel in Windows]{Kernel in Windows \acro{XP}, 2000, Win \NT} \begin{itemize} \item In \texttt{\%SystemRoot\%\bs{}System32} \begin{itemize} \item \texttt{\%SystemRoot\%} = \texttt{C:\bs{}winnt}, or \texttt{D:\bs{}winnt},\ldots \end{itemize} \item Called \texttt{ntoskrnl.exe} \item Microsoft call it a \emphcolour{layered kernel} or \emphcolour{microkernel}. \item sometimes called the ``Executive services'' and the ``\NT executive'' \item Bottom layer is the \emphcolour{hardware abstraction layer} \end{itemize} \end{slide} \begin{slide}[bm=What does an OS do?]{What does an \OS do?} \begin{itemize} \item Provides a ``government'' to share out the \emphcolour{hardware resources} fairly \item Provides a way for the programmer to easily work with the hardware and software through a set of \emphcolour{system calls} --- see slides \S\ref{sld:system-calls-1}--\S\ref{sld:system-calls-windows}. \begin{itemize} \item Sometimes also called \emphcolour{supervisor calls} \end{itemize} \end{itemize} \end{slide} \begin{slide}[bm=User Friendly OS]{Is there a User Friendly \OS?} \begin{itemize} \item Some people have said that the Windows \OS{}s are more user friendly than Linux \item Can this be the case? \begin{itemize} \item Are the \emphcolour{system calls} more user friendly? \begin{itemize} \item (see slides \S\ref{sld:system-calls-1}--\S\ref{sld:system-calls-windows} for more about system calls) \end{itemize} \item Does Windows \emphcolour{manage the hardware} in a more user friendly way? \end{itemize} \item No! \item The user interface is not an operating system issue. See your subject Human Computer Interfaces (\HCI) \item Do you want a more user friendly interface for Linux? \begin{itemize} \item Then write one! Contribute to the Gnome or \KDE projects. \end{itemize} \end{itemize} \end{slide} \begin{slide}[bm=Example: MAC OS X]{Example: \MAC \OS X} \begin{itemize} \item The Mac has a deserved reputation for a great user interface \item \OS X is the latest \OS from Apple \item Very beautiful, easy to use \item But it is Unix, built on Free\BSD! \begin{itemize} \item The Unix that till now has mostly been used on servers; \item considered by some to be less user friendly than Linux \end{itemize} \item The User Interface is not part of the \OS \end{itemize} \end{slide} \begin{slide}[toc=IE part of Windows?,bm=Is IE part of Windows?]% {Is \acro{IE} part of Windows \OS{}s?} \begin{itemize} \item Is Internet Explorer part of the Windows operating systems? \item Please discuss this question with your neighbour. \item See {\footnotesize \url{http://news.com.com/2100-1001-219029.html?legacy=cnet}} \end{itemize} \end{slide} \begin{slide}[bm=What resources?,toc=What resources?]% {What resources does \OS manage?} \begin{itemize} \item The \OS manages resources such as: \begin{itemize} \item Use of \CPU \item Memory \item Files and disk access \item Printing \item Network access \item \IO devices such as keyboard, mouse, display, \USB devices,\,\ldots \end{itemize} \end{itemize} \end{slide} \begin{slide}{\ldots{}Allocated to who/what?} \begin{itemize} \item An operating system can be \emphcolour{multiuser} \begin{itemize} \item In this case, resources must be allocated to the users fairly \end{itemize} \item ``Proper'' operating systems are \emphcolour{multitasking} \begin{itemize} \item Resources must be allocated fairly to the processes \end{itemize} \item Users, processes must be protected from each other. \end{itemize} \end{slide} \begin{slide}{Kernel mode and user mode} \begin{itemize} \item \emphcolour{Kernel} means ``central part'' \item The kernel is the central part of \OS \item It is a program running at all times \item Application programs run in ``\emphcolour{user mode}'' \begin{itemize} \item Cannot access hardware directly \end{itemize} \item Kernel runs in ``\emphcolour{kernel mode}'' (or ``\emphcolour{supervisor mode}'') \begin{itemize} \item \emphcolour{Can access hardware, special \CPU registers} \end{itemize} \end{itemize} \end{slide} \begin{slide}[toc=Access Hardware?]{How does user program access hardware?} \begin{itemize} \item A program that writes to the disk accesses hardware \item How? \item Standard library call, e.g., \texttt{fprintf()} \item Library contains \textbf{\emphcolour{system calls}} \begin{itemize} \item see slides \S\ref{sld:system-calls-1}--\S\ref{sld:system-calls-windows} \end{itemize} \item A system call passes the request to the kernel \item The kernel, (executing in kernel mode always) writes to the disk \item Returns telling user program that it was successful or not \end{itemize} \end{slide} \tsection{System Calls} \begin{slide}[bm=System calls,toc=System calls]% {Kernel: programmers' standard interface} \label{sld:system-calls-1} \begin{itemize} \item This is the \emphcolour{second important function} of the operating system \item Provides a standard set of \emphcolour{system calls}, used by the libraries \item User programs usually use the system calls indirectly \begin{itemize} \item since libraries give higher level interface \end{itemize} \end{itemize} \end{slide} \begin{slide}{System Call} \label{sld:system-calls-2} \begin{itemize} \item Low level details: \begin{itemize} \item \CPU provides a \emphcolour{trap} instruction which puts the \CPU into a priveleged mode, i.e., kernel mode \begin{itemize} \item On Intel ix86 architecture, the trap instruction is the \texttt{int~0x80} instruction \item See \texttt{include/asm-i386/unistd.h} and \texttt{arch/i386/kernel/entry.S} in Linux source code. See also {\tiny \url{http://en.tldp.org/LDP/khg/HyperNews/get/syscall/syscall86.html}} \end{itemize} \item Sometimes called a \emphcolour{software interrupt} \item put parameters into \CPU registers before the call \item save values of many registers on a stack \end{itemize} \item High level: all this buried in external library interface \end{itemize} \end{slide} \begin{slide}{System Calls --- Linux} \label{sld:system-calls-linux} \begin{itemize} \item \POSIX specifies particular function calls that usually map directly to system calls --- see \texttt{man} section 2 \item Provide a higher level interface to system calls \item Less than 300 of them. Examples: \end{itemize} {\footnotesize\setlength{\extrarowheight}{0pt}% \begin{tabularx}{\slideWidth}{@{}>{\ttfamily}lY@{}} \toprule% \textnormal{\textbf{Call}} & \textnormal{\textbf{Description}}\\ \midrule% pid = fork() & Create a child process identical to parent process\\ exit( status ) & Terminate process and return status\\ fd = open( file, O\_RDONLY ) & Open a file for reading, writing or both \\ status = close( fd ) & Close an open file \\ n = read( fd, buffer, nbytes ) & Read data from file into a buffer \\ n = write( fd, buffer, nbytes ) & Write data from buffer into a file \\ status = chdir( dirname ) & Change working directory of process \\ \bottomrule \end{tabularx}} \end{slide} \begin{slide}[bm=Windows System Calls,toc=Windows System Calls]% {System Calls --- Windows and Win32 \acro{API}} \label{sld:system-calls-windows} \begin{itemize} \item Win32 \API provides many thousands of calls \item No one-one mapping to system calls \item Not all make a system call \item On some versions of Windows \OS{}s, graphics calls are system calls, on others they are not \item Win32 \API documented on \acro{MSDN}. Examples: \end{itemize} %\par\vspace*{-1ex}\par \newlength{\adj} {\footnotesize\setlength{\extrarowheight}{0pt}% \setlength{\adj}{-0.5ex}% \begin{tabularx}{\slideWidth}{@{}>{\ttfamily}l>{\ttfamily}lY@{}} \toprule% \textnormal{\textbf{POSIX}} & \textnormal{\textbf{Win32}} & \textnormal{\textbf{Description}}\\ \midrule% fork & CreateProcess & create a new process\\[\adj] exit & ExitProcess & Terminate execution \\[\adj] open & CreateFile & Create a file or open existing file \\[\adj] close & CloseHandle & Close a file \\[\adj] read & ReadFile & Read data from a file \\[\adj] write & WriteFile & Write data to a file \\ \bottomrule \end{tabularx}} \end{slide} \tsection{Types of OS} \begin{slide}{Types of Operating System} \mbox{} \vspace*{0.15\slideWidth} \begin{center}\Large \mbox{}\blue{}A rough breakdown of the types of \OS \end{center} \vspace*{\stretch{1}} \mbox{} \end{slide} \begin{slide}[bm=Types of OS?,toc=Types of OS?]% {What types of operating systems are there?} \begin{itemize} \item There are {\blue{}four main categories}; depends on \emphcolour{organisation} of the \emphcolour{kernel} \item \emphcolour{Monolithic} operating systems \begin{itemize} \item {\mbox{}\blue{}Linux} is a monolithic \OS \end{itemize} \item \emphcolour{Layered} operating systems \begin{itemize} %% \item \NT started as a layered \OS, but much more was moved to %% kernel to improve performance \item {\mbox{}\blue{}Windows \NT/2000/\XP/2003} is described as a layered architecture \end{itemize} \item \emphcolour{Microkernel with client server architecture} \begin{itemize} \item The {\mbox{}\blue{}\acro{QNX}} real-time \OS is truly a microkernel; the kernel is said to be only eight kilobytes in size! \item Andrew Tanenbaum wrote the {\blue{}\acro{MINIX}} operating system as an example microkernel \OS for students to study \item The {\blue{}\GNU Hurd} \OS has a microkernel architecture \item {\mbox{}\blue{}Windows 2000} is described as having a hybrid layered-microkernel architecture, although Andrew {\green{}Tanenbaum disagrees}: \url{http://www.cs.vu.nl/~ast/brown/} \end{itemize} \item \emphcolour{Virtual machine} architecture \end{itemize} \end{slide} \tsection{Monolithic Kernel} \begin{slide}{Monolithic Kernel} \begin{itemize} \item A monolithic kernel has all \emphcolour{procedures} in the same \emphcolour{address space}. \begin{itemize} \item This means that all the code can see the same global variables, same functions calls, and \item there is only one set of addresses for all the kernel \end{itemize} \item Purpose is \emphcolour{speed}: \begin{itemize} \item to reduce overhead of communication between layers \end{itemize} \end{itemize} \end{slide} \begin{slide}{Monolithic kernel --- 2} \begin{center} \includegraphics[width=\slideWidth]{monolithic} \end{center} \end{slide} \begin{slide}{Structure in a Monolithic Kernel} \begin{itemize} \item To avoid chaos, a monolithic kernel must be well structured \item Linux kernel uses \emphcolour{loadable modules}, which support hardware and various software features \item Such as \RAID, Logical Volume Managers, various file systems, support for various networking protocols, firewalling and packet filtering,\ldots \end{itemize} \end{slide} \begin{slide}{Monolithic kernel: loadable modules} \begin{center} \includegraphics[width=\slideWidth]{monolithic-with-modules} \end{center} \end{slide} \begin{slide}{Monolithic kernel: Loadable Modules} \begin{itemize} \item Loadable modules in Linux kernel support: \item \emphcolour{Dynamic Linking:} modules can be loaded and linked with the kernel, or unloaded, while kernel is executing \item \emphcolour{Stackable Modules:} Modules can provide support for each other, so many modules can be stacked on a lower level module. \item Reduces replication of code \item Hierarchical structure ensures that modules will remain loaded while required \item View loaded modules by typing lsmod \end{itemize} \end{slide} \tsection{Layered Kernel} \begin{slide}{Layered kernel} \begin{itemize} \item Has different levels; example: \item Lowest level manages hardware \item Next level up manages, e.g., memory and disks \item Next level up manages \IO,\ldots. \item Each layer may have its own address space \item Communication between layers requires overhead \item Advantage is different layers cannot interfere with each other. \end{itemize} \end{slide} \begin{slide}{Layered Kernel --- 2} \begin{center} \includegraphics[width=0.9\slideWidth]{layered-system} \end{center} \end{slide} \tsection{Microkernel} \begin{slide}{Microkernel with Client-Server Arch.} \begin{itemize} \item \emphcolour{Microkernel} architecture keeps the kernel \emphcolour{as small as possible}, for the sake of reliability and security \item {\mbox{}\blue{}As much is done in the user space as possible} \item User space provides servers, such as memory server, file server, terminal server, process server \item Kernel directs requests from user programs to user servers \end{itemize} \end{slide} \begin{slide}{Microkernel Architecture --- 2} \begin{center} \includegraphics[width=\slideWidth]{microkernel} \end{center} \end{slide} \begin{slide}{Microkernel Architecture --- 3} \begin{itemize} \item Most of operating system is a set of user processes \item the server processes do most of the work \item The microkernel mostly just passes requests from client processes to server processes \end{itemize} \begin{center} \includegraphics[width=0.5\slideWidth]{microkernel-messages} \end{center} \end{slide} \begin{slide}{Microkernel Architecture --- Examples} \begin{itemize} \item Mach kernel used as core for many \UNIX \OS \begin{itemize} \item including the \MAC \OS X \end{itemize} \item \GNU Hurd \OS, initiated by Richard Stallman for the \GNU project \item The \QNX distributed real-time \UNIX-like \OS \begin{itemize} \item kernel only 8\,KB in size! \end{itemize} \item It can be \emphcolour{debated} whether Windows \NT/2000/\XP/2003 operating systems are microkernels: \begin{quote} ``With all the security problems Windows has now, it is increasingly obvious to everyone that tiny microkernels, like that of \acro{MINIX}, are a better base for operating systems than huge monolithic systems.''\par \begin{flushright} --- Prof. Andrew Tanenbaum, \url{http://www.cs.vu.nl/~ast/brown/} \end{flushright} \end{quote} \end{itemize} \end{slide} \begin{slide}{Windows 2000 Architecture} \begin{itemize} \item Windows 2000 is described as a hybrid between a layered architecture and microkernel architecture. \item \HAL provides an abstract machine---aim to make porting to other hardware architectures easier \item \HAL + Microkernel $\approx$ normal microkernel \end{itemize} \par\medskip\par% \begin{center} \includegraphics[width=0.7\slideWidth]{windows-2000-arch} \end{center} \end{slide} \begin{slide}{Windows 2000 Architecture --- 2} \begin{itemize} \item Environment subsystem aims to support DOS, Win32, OS/2 applications \begin{itemize} \item each environment subsystem uses a \DLL (dynamic link library) to convert system calls to Windows 2000 calls \end{itemize} \item The \IO manager contains file system and device drivers \item Microkernel, \HAL and ``many functions of the executive'' execute in kernel mode. \begin{itemize} \item {\mbox{}\blue{}Sacrifice advantage of microkernel} of reduced code executing in kernel mode \item to {\blue{}reduce communication overhead} \end{itemize} \end{itemize} \end{slide} \tsection{Virtual machine} \begin{slide}{Virtual machine} \begin{itemize} \item Virtual hardware \item Many operating systems run independently on same computer \item \IBM now selling \emphcolour{mainframes} running many instances of Linux to Telecom companies --- see next slides %% \begin{itemize} %% \item Examples: %% \begin{itemize} %% \item The original \IBM \acro{VM} \OS was called \acro{CP/CMS}, %% later called \acro{VM/370} since it ran on the S/370 %% mainframe, then renamed to %% \item \acro{VM/ESA}, ran on S/390 mainframe hardware %% \item z\acro{VM}$^{\text{\textregistered}}$ running on zSeries mainframes %% supports running many different \OS, particularly Linux. %% \url{http://www.vm.ibm.com/} %% \end{itemize} %% \item Some useful sites: %% \begin{itemize} %% \item VM at MIT: \url{http://mitvma.mit.edu/system/vm.html} %% {\tiny %% \item An old article: %% \url{http://www.linuxplanet.com/linuxplanet/reports/1532/1/}} %% \end{itemize} %% \end{itemize} \item \emphcolour{VMWare} allows something similar on \PC: \url{http://www.VMWare.com} \item \url{http://www.connectix.com/} used to sell \emphcolour{Virtual PC} and \emphcolour{Virtual Server}, but they have been bought out by Microsoft, who of course, have dropped Linux support: \url{http://www.msfn.org/comments.php?id=5516&catid=1} \item \emphcolour{Java Virtual machine} also provides virtual hardware that all programs can execute on. \end{itemize} \end{slide} \begin{slide}[bm=Virtual Machine OS Examples]{Virtual Machine \OS Examples} \begin{itemize} \item \IBM designed the \acro{CP/CMS} virtual \OS for their S/360 mainframe. \item Later called \acro{VM/370} to run on their S/370 mainframes \item Later called \acro{VM/ESA} on the S/390 hardware \item Now sold as z\acro{VM}$^{\text{\textregistered}}$ running on zSeries mainframes \begin{itemize} \item Supports running many different \OS, particularly Linux \item See \url{http://www.vm.ibm.com/} \end{itemize} \item See how \acro{MIT} run Linux on \acro{VM/ESA} on their S/390 mainframe: \url{http://mitvma.mit.edu/system/vm.html} \item Search the web for articles on Linux running on mainframes. \end{itemize} \end{slide} \begin{slide}{Linux on zVM on ZSeries Mainframe} \begin{center} \includegraphics[width=0.9\slideWidth]{mainframe-running-linux} \end{center} \end{slide} \begin{slide}{Many Individual Machines} \begin{itemize} \item A data centre may have many servers \begin{itemize} \item Each must be powerful enough to meet \emphcolour{peak demand} \item Most are not at peak demand most of the time \item \ldots{}so most are \emphcolour{underused} \item \ldots{}but must pay for electricity for cooling, and for powering all that \emphcolour{reserve capacity} \end{itemize} \end{itemize} \end{slide} \begin{slide}{Many Virtual Machines, one Mainframe} \begin{itemize} \item Can replace many individual servers with one mainframe running many instances of an \OS such as Linux \begin{itemize} \item The demand spread out among all the virtual machines, \item total \emphcolour{utilisation high} --- demand shared \item busy virtual machines get more \CPU power to meet peak demand \item Much lower power requirements \item Much less air conditioning cost \item Much less floor space required \end{itemize} \item Virtual machines partitioned from each other, like the individual machines in data centre \end{itemize} \end{slide} \begin{slide}{With Kernels, ``small is beautiful''} \begin{itemize} \item The \emphcolour{reliable operation} of any computer depends on its operating system, i.e., it's kernel. \item More complex software has \emphcolour{higher chance of bugs}, security problems, vulnerability to worms and viruses \item Linus Torvalds imposes a strict discipline on kernel developers to carefully restrict code that will increase size of kernel \item Linux does not suffer from ``kernel bloat'' \begin{itemize} \item Compare the size of the Windows 2000 ``microkernel:'' several megabytes, cannot be booted from floppy \item Linux: small enough to fit on one floppy together with many useful tools: \url{http://www.toms.net/rb/} \end{itemize} \item \emphcolour{Movies}: \begin{itemize} \item Linus \href{run:microkernel.mpg}{discusses Monolithic, Microkernel design}, \href{run:linux.mpg}{ETU}, \href{run:microkernel.avi}{avi}, \href{run:microkernel-0.avi}{avi2} \end{itemize} \end{itemize} \end{slide} \tsection{Boot Process} \begin{slide}{Booting an Operating System} \vspace*{0.15\slideWidth} \begin{center}\large \mbox{}\blue{}The \OS manages the hard disks. \vspace*{0.05\slideWidth} \mbox{}\blue{}How can the system read the hard disk to start the \OS? \end{center} \end{slide} \begin{slide}[bm=Booting a PC]{Booting a \PC} \begin{itemize} \item The process of starting the computer ready for use \item How does a computer boot? \item Involves: \item \BIOS (``basic input output system'') finding the \emphcolour{boot loader} \item The boot loader starting the kernel \item For Linux: \item The kernel starting \texttt{init} \item \texttt{init} starting everything else \end{itemize} \end{slide} \begin{slide}{Boot Loader} \begin{itemize} \item A \emphcolour{boot loader} is a piece of software that runs before any operating system, and is \item responsible for loading an operating system kernel, and transferring control to it \item Microsoft \OS provides a boot loader that starts their \OS from the first active primary partition \item We use the grub (Grand Unified Boot Loader) boot loader that can start any operating system from almost any hard disk, floppy or network. \end{itemize} \end{slide} \begin{slide}[bm=Boot Process,toc=Boot Process]{The boot process for a \PC} \begin{itemize} \item the \BIOS performs a power on self-test (\POST) \item the \BIOS initialises \PCI (Peripheral Component Interconnect) devices \item the bootloader loads the first part of the kernel into system \RAM \item the kernel identifies and initialises the hardware in the computer \item the kernel changes the \CPU to protected mode \item \texttt{init} starts and reads the file \texttt{/etc/inittab} \item the system executes the script \texttt{/etc/rc.d/rc.sysinit} \item the system executes scripts in \texttt{/etc/rc.d/init.d} to start services (daemons) \end{itemize} \end{slide} \begin{slide}[bm=BIOS,toc=BIOS]{Before the bootloader: The \BIOS} \begin{itemize} \item The \BIOS runs in \emphcolour{real} mode (like old 8086) \item \BIOS tests hardware with basic Power On Self Test (\POST) \item \BIOS then initialises the hardware. \item Very important for the \PCI devices, to ensure no conflicts with interrupts. \item See a list of \PCI devices. \item \BIOS settings determine order of boot devices; when finds one, loads first sector into \RAM, starts executing that code. \end{itemize} \end{slide} \begin{slide}{VMWare Boot Screen} \begin{center} \includegraphics[width=0.85\slideWidth]{post-2} \end{center} \end{slide} %% \begin{slide}{The Boot Loader} %% \begin{itemize} %% \item Microsoft \OS{}es use the Master Boot Record (\MBR) to hold code %% that reads the first sector from the first active primary %% partition. %% \item Linux uses a boot loader to read kernel into \RAM %% \item There are a number of boot loaders: %% \begin{itemize} %% \item \LILO: LInux LOader %% \item Grub (Grand Unified Boot Loader) %% \item Syslinux: used on rescue disks to boot from a \FAT file system %% \item Loadlin: can start Linux from an already booted \DOS system %% \end{itemize} %% \end{itemize} %% \end{slide} \begin{slide}{Boot Loaders: what they do} \begin{itemize} \item Syslinux is the simplest, grub has the most features, \LILO in between \item Grub provides many interactive commands that allow: \begin{itemize} \item Reading many different file systems \item Interactively choosing what to boot \item Many, many more things (do pinfo grub) \item All before any operating system started!! \end{itemize} \item Grub and \LILO let you choose what \OS to boot \end{itemize} \end{slide} \begin{slide}{The kernel is loaded} \begin{itemize} \item Boot loader reads first part of the kernel into \RAM, executes the code \item This initial kernel code loads the rest of the kernel into \RAM \item The kernel checks the hardware again \item The kernel switches from \emphcolour{real} mode to \emphcolour{protected} mode \end{itemize} \end{slide} \begin{slide}{Real and Protected mode} \begin{itemize} \item {\mbox{}\blue{}\textbf{Real mode}} exists for booting, and so that can run old \DOS programs \item Uses only bottom 16 bits of registers \item Can only access the bottom 1 \MB \RAM \item \BIOS only supports real mode \item {\mbox{}\blue{}\textbf{Protected mode}} uses all 32 bits of address registers \item Allows access to all \RAM \item Allows use of memory management unit \item Normal mode of operation for modern \OS{}es on Intel platform. \item Cannot call \BIOS functions in protected mode \end{itemize} \end{slide} \begin{slide}[bm=init,toc=init]{Kernel in Protected Mode: \texttt{init}, \PID 1} \begin{itemize} \item The kernel then starts the \emphcolour{first process}, process 1: \texttt{/sbin/init} \item \texttt{/sbin/init} reads the \texttt{/etc/inittab} \item Init starts reading the script /etc/rc.d/rc.sysinit \item \texttt{/etc/inittab} tells \texttt{init} to do this \item \texttt{init} then executes scripts in \texttt{/etc/rc.d/init.d} to start services \end{itemize} \end{slide} \tsection{Runlevels} \begin{slide}{Runlevels} \begin{itemize} \item A standard Linux system has 7 modes called \emphcolour{runlevels}: \begin{itemize} \item[0:] halt (shut down the machine) \item[1:] single user mode \item[2:] multiuser with no network services \item[3:] full mulituser mode \item[4:] can be customised; default same as 3 \item[5:] multiuser with graphical login \item[6:] reboot \end{itemize} \end{itemize} \end{slide} \begin{slide}{Directories for each runlevel} \begin{itemize} \item If you look in \texttt{/etc/rc.d}, you see one directory for each runlevel, and a directory called \texttt{init.d}: \begin{alltt}\footnotesize $ \textbf{ls /etc/rc.d} {\blue{}init.d rc0.d rc2.d rc4.d rc6.d} {\green{}rc.sysinit} {\green{}rc} {\blue{}rc1.d rc3.d rc5.d} {\green{}rc.local} \end{alltt}%$ \item \texttt{init.d} contains one script for each service. You execute these scripts with the \texttt{service} command, i.e., \begin{alltt} $ \textbf{sudo service autofs start} \end{alltt}%$ \end{itemize} \end{slide} \begin{slide}{Runlevel directories} \begin{itemize} \item Each of \texttt{/etc/rc.d/rc[0-6].d} contains \emphcolour{symbolic links} to scripts in \texttt{/etc/rc.d/init.d} \begin{itemize} \item A symbolic link is a bit like a shortcut in Windows (but more fundamental) \item We cover symbolic links in detail later \end{itemize} \item If name of link begins with \texttt{K}, the script will stop (\emphcolour{\underline{k}ill}) the service \item If name of link begins with \texttt{S}, will start the service \item The \texttt{chkconfig} program creates these symbolic links \end{itemize} \end{slide} \begin{slide}[bm=yum]{Example of service: \texttt{yum}} \begin{itemize} \item In the laboratory, you set up the \texttt{yum} service to automatically install software updates \item You used the \texttt{chkconfig} program to enable the service. \begin{itemize} \item For a complete manual on \texttt{chkconfig}, type: \begin{alltt} $ \textbf{man chkconfig} \end{alltt}%$ \item For a brief summary of options, type: \begin{alltt} $ \textbf{/sbin/chkconfig --help} \end{alltt}%$ \end{itemize} \item Here we use the program \texttt{find} (covered in detail later) to see the links before and after \end{itemize} \end{slide} \begin{slide}[bm=Turning yum off,toc=Turning yum off]% {Turning \texttt{yum} Service Off} \begin{itemize} \item \begin{alltt}\tiny $ \textbf{sudo /sbin/chkconfig yum off} $ \textbf{/sbin/chkconfig yum --list} yum 0:off 1:off 2:off 3:off 4:off 5:off 6:off $ \textbf{find /etc/rc.d -name '*yum'} /etc/rc.d/init.d/yum /etc/rc.d/rc0.d/K01yum /etc/rc.d/rc1.d/K01yum /etc/rc.d/rc2.d/K01yum /etc/rc.d/rc3.d/K01yum /etc/rc.d/rc4.d/K01yum /etc/rc.d/rc5.d/K01yum /etc/rc.d/rc6.d/K01yum \end{alltt}%$ \item After turning the service off, all the links start with `\texttt{K}' in all runlevels: 0, 1, 2, 3, 4, 5 and 6. \end{itemize} \end{slide} \begin{slide}[bm=Turning yum on,toc=Turning yum on]% {Turning \texttt{yum} Service On} \begin{itemize} \item \begin{alltt}\tiny $ \textbf{sudo /sbin/chkconfig yum on} $ \textbf{/sbin/chkconfig yum --list} yum 0:off 1:off 2:on 3:on 4:on 5:on 6:off $ \textbf{find /etc/rc.d -name '*yum'} /etc/rc.d/init.d/yum /etc/rc.d/rc0.d/K01yum /etc/rc.d/rc1.d/K01yum /etc/rc.d/rc2.d/S50yum /etc/rc.d/rc3.d/S50yum /etc/rc.d/rc4.d/S50yum /etc/rc.d/rc5.d/S50yum /etc/rc.d/rc6.d/K01yum \end{alltt}%$ \item Notice that after turning the service on, there are links that start with `\texttt{S}' in runlevels 2, 3, 4 and 5. \end{itemize} \end{slide} \tsection{References} \begin{slide}{References} \label{sld:references} %\tiny \begin{itemize} \item \emph{Modern Operating Systems}, Second Edition, Andrew S. Tanenbaum, Prentice Hall, 2001, Chapter 1. Good discussion of system calls. \item \emph{Operating Systems}, Fourth Edition, William Stallings, Prentice Hall, 2001, chapter 2 particularly pp 85--91 and 98-99, chapter 4, pp 172--178 \item \emph{Operating Systems: A Concept Based Approach}, D. M. Dhamdhere, McGraw Hill, 2002 \end{itemize} \end{slide} \end{document}