CS 346 – Chapter 2

• OS services– OS user interface– System calls– System programs

• How to make an OS– Implementation– Structure– Virtual machines

• Commitment – For next day, please finish chapter 2.

OS services

2 types• For the user’s convenience

– Shell– Running user programs– Doing I/O– File system– Detecting problems

• Internal/support– Allocating resources– System security– Accounting

• Infamous KGB spy ring uncovered due to discrepancy in billing of computer time at Berkeley lab

User interface

• Command line = shell program– Parses commands from user– Supports redirection of I/O (stdin, stdout, stderr)

• GUI– Pioneered by Xerox PARC, made famous by Mac– Utilizes additional input devices such as mouse– Icons or hotspots on screen

• Hybrid approach– GUI allowing several terminal windows– Window manager

System calls

• “an interface for accessing an OS service within a computer program”

• A little lower level than an API, but similar

• Looks like a function call

• Examples– Performing any I/O request, because these are not defined by the

programming language itself

e.g. read(file_ptr, str_buf_ptr, 80);– assembly languages typically have “syscall” instruction.

When is it used?

How?

• If many parameters, they may be put on runtime stack

Types of system calls

• Controlling a process

• File management

• Device management

• Information

• Communication between processes• What are some specific examples you’d expect to find?

System programs

• Also called system utilities• Distinction between “system call” and “system program”• Examples

– Shell commands like ls, lp, ps, top– Text editors, compilers– Communication: e-mail, talk, ftp– Miscellaneous: cal, fortune– What are your favorites?

• Higher level software includes:– Spreadsheets, text formatters, etc.– But, boundary between “application” and “utility” software is

blurry. A text formatter is a type of compiler!

OS design ideas

• An OS is a big program, so we should consider principles of systems analysis and software engineering

• In design phase, need to consider policies and mechanisms– Policy = What should we do; should we do X– Mechanism = how to do X

– Example: a way to schedule jobs (policy)

versus: what input needed to produce schedule, how schedule decision is specified (mechanism)

Implementation

• Originally in assembly

• Now usually in C (C++ if object-oriented)

• Still, some code needs to be in assembly– Some specific device driver routines– Saving/restoring registers

• We’d like to use HLL as much as possible – why?

• Today’s compilers produce very efficient code – what does this tell us?

• How to improve performance of OS:– More efficient data structure, algorithm– Exploit HW and memory hierarchy– Pay attention to CPU scheduling and memory management

Kernel structure

• Possible to implement minimal OS with a few thousand lines of code monolithic kernel– Modularize like any other large program– After about 10k loc, difficult to prove correctness

• Layered approach to managing the complexity– Layer 0 is the HW– Layer n is the user interface– Each layer makes use of routines and d.s. defined at lower

levels– # layers difficult to predict: many subtle dependencies– Many layers lots of internal system call overhead

Kernel structure (2)

kernel – Kernel = minimal support for processes and memory management– (The rest of the OS is at user level)– Adding OS services doesn’t require changing kernel, so easier to

modify OS– The kernel must manage communication between user program and

appropriate OS services (e.g. file system)– Microsoft gave up on kernel idea for Windows XP

• OO Module approach– Components isolated (OO information hiding)– Used by Linux, Solaris– Like a layered approach with just 2 layers, a core and everything

else

Virtual machine

• How to make 1 machine behave like many• Give users the illusion they have access to real HW,

distinct from other users• Figure 2.17 levels of abstraction:

– Processes / kernels / VM’s / VM implementations / host HW

As opposed to:– Processes / kernels / different machines

• Why do it?– To test multiple OS’s on the same HW platform– Host machine’s real HW protected from virus in a VM bubble

VM implementation

• It’s hard!– Need to painstakingly replicate every HW detail, to avoid giving away

the illusion– Need to keep track of what each guest OS is doing (whether it’s in

kernel or user mode)– Each VM must interpret its assembly code – why? Is this a problem?

• Very similar concept: simulation– Often, all we are interested in is changing the HW, not the OS; for

example, adding/eliminating the data cache– Write a program that simulates every HW feature, providing the OS with

the expected behavior