CMSC 421 Operating Systems Lecture Notes (c) 1997 Howard E. Motteler Introduction and Overview ========================== Reading -------- Read all of Chapter 1, which will be covered the first week of class Chapter 1 presents a valuable overview and introduction to material covered in more detail in later chapters We will cover excepts of the systems call section, and occasionally return there It is also (along with the associated man pages) a useful reference, as the POSIX sys calls are applicable for most Unix systems Use of Minix ------------- Operating system theory (as generally taught) is not always that closely related to practice - subjects of practical importance, like i/o and file systems, are shorted in a theoretical course, - subjects of less practical importance, like scheduling, are covered perhaps more than their usefulness warrants Minix provides us with valuable examples and a case study, while not being *too* complicated to cover in a semester Minix can run on almost any 80X86 system The Bochs emulator can emulate an 80386 CPU and associated PC hardware (like disks and video) on a Unix/X system We will study Minix, and make modest modifications and extensions to it (You don't have to use Minix for your day-to-day work,though if you have an older machine, it is a very reasonable choice) This is a course in *operating systems*, not systems administration; but we will necessarily cover some issues in systems administration, in setting up our Minix systems 1.1 What is an Operating System? --------------------------------- One view: the OS provides the programmer with a (relatively) easy to use virtual machine Systems calls can be thought of as commands for a high-level virtual machine For example, the file sys calls creat(), open(), read(), write(), close(), are *much* easier to use than the underlying hardware (The Bochs emulator is another sort of virtual machine) Another view: the OS manages all the system's actual resources: memory, disk space, processors, i/o devices, and so on Both views are part of the whole picture 1.3.1 Processes ---------------- A process is a program in execution Each process has its own - address space - registers, PC & SP - open files, cwd - pid (unique identifier) The system must be able to suspend and restart processes e.g., for timesharing Thus, it must be able to save the entire *process state* Processes may communicate via pipes, messages, shared memory, or signals Unix processes are created with the fork() systems call, A single process "forks" into a parent and a child (Processes will be covered in more detail in Chapter 2) 1.3.2 Files ------------ We assume students are already familiar with basics of Unix files - hierarchical directories - protection codes Unix *mount* command attaches other devices to root file system (thus no dos-like c:/path1 and d:/path2) Unix has *special files* for devices and pipes e.g., /dev/tty /def/hda /dev/hda1 /dev/hda2 (File systems will be covered in detail in Chapter 5) 1.4 System Calls ------------------ System calls are the programmer's view of an OS To a large extent, they determine what an OS does Minix has systems calls for - process management - signals - file management - directory and file system management - protection - time management A "real" systems call is something like a procedure call Part of the process state--registers, PC, SP, etc--is saved A *trap* instruction (or some means of switching from user to kernel mode) is then executed The system checks the parameters passed (possibly verifying the request against other process or user info) and then performs the requested action The system then returns control back to the user process Above the assembly language level, "systems calls" are really library routines These may be a simple wrapper around a real systems call (the Unix "man 2" sections, e.g., read) Or they may be more complex library routines (the Unix "man 3" sections, e.g., fread) [ give examples of a couple of Minix sys calls ] 1.5 Operating System Structure -------------------------------- Particular operating systems can be classified as - monolithic - layered - virtual machines - client-server model Monolithic ----------- The OS is a collection of procedures (and interrupt handlers that can call each other (Most "real" OSes are more or less monolithic) Layered -------- This is an attempt to enforce some order among the set of OS procedures For example, we might have three layers - Main procedure: a gateway for sys calls - A collection of service procedures (we would have procedures for most sys calls, and various "internal" procedures (e.g., the scheduler) as well - A collection of "lower-level" utility procedures. This would include all the code that deals directly with the hardware: device drivers, interrupt handlers, etc. More complex layered systems include Multics and the THE system Multics used was organized as a set of rings (with inner more privileged than outer) Procedures in outer rings had to call procedures inner rings with a trap instruction (a generalization of sys call) The whole OS (including file system?) was in the address of every process, and the access restrictions were enforced by the hardware Virtual Machines ----------------- The IBM VM/370 OS could provide the user with an entire virtual 370 (with reasonably efficient emulation) This completely separated multiprogramming (done at a lower level to allow multiple virtual machines) from the issue of providing a convenient programming model. IBM ran multiple instances of CMS (its time sharing system) as a single task on a virtual machine 80386 and higher Intel chips provided a virtual 8086 mode, mainly for DOS execution (But the 80386 doesn't support--at least not in hardware--the emulation of concurrent multiple 80386s, as VM/370 did) The Bochs emulator can emulate an 80386 CPU and associated PC hardware (like disks and video) on any Unix/X system, including Unix running on an 80386 The Linux DOSEMU and WINE emulators emulate DOS and Windows by trapping the sys calls back to the emulator, rather than emulating everything Thus Bochs can run Minix, but DOSEMU (or WINE) can not DOSEMU and WINE have to run on an 80x86 (for x > 2) Client-Server Model -------------------- Basic Idea: move as many "systems" functions as possible to the user level, and have only a minimal kernel Such a system might look something like this user |... process | tty |... file | memory user process | server | server | server | server mode ---------------------------------------------------- . . messages . . . . . . . . . messages . . . . . kernel Kernel mode In such a minimal system, the kernel would handle only - messages - processes Advantages include - simplicity - reliability - modularity - application to distributed systems The main disadvantage is in performance; there is usually more overhead for a message than a procedure call The Mach micro-kernel is an example of such a system