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: , 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