cs357 Lecture Notes Spring 2000 Week 1, Thursday Concepts -------- 1) The axis of possible operating systems MacOS and DOS operate at virtually identical points in terms of capabilities, relibility and user interface UNIX is the most different thing out there. You can't understand tradeoffs until you see the alternatives. No opinions! at least not until the end of the semester. 2) The API The operating system defines a set of capabilities that applications can count on. The design of the OS/application interface is the most important design decision that affects programmers and (ultimately) users 3) Concurrency How does the OS implement multitasking? How can we write concurrent applications? 4) theoretical understanding of each component of an OS. Skills ------ 1) a little C programming and UNIX 2) experimental design Given what you want to know, what can you measure to find the answer. We'll start with labs where I tell you what to do and all you have to do is interpret the results. Gradually, I will tell you less and less about what to do, and more about what we want to know. 3) written presentation of experimental results data interpretation and presentation technical writing Experiments ----------- 1) Not all the experiments will work the first time! The real world is messy, and things that should work in theory often don't. We are often trying to peer beneath a layer of abstraction that is _deliberately_ opaque. 2) Not all the experiments will work at all! Sometimes we just can't find what we want to know. 3) I do not have all the answers. You will see a lot of inexplicable things. I cannot explain them. Careful experimental design and execution will reduce the number of inexplicable things you encounter. This uncertainty and open-endedness is exactly what I think makes this class interesting, and I hope will make it valuable in the future. (For computer science research, this kind of exploration is almost always the first step in working with a new system, and is sometimes a sufficient unit of publication). Chapter 1 --------- Read Chapter One An operating system is a software layer between application programmers and hardware. It is largely defined by: 1) the API, or virtual machine interface 2) the hardware interface 3) the performance consequences of its implementation This view will reappear in this class several times as we looks at various OS components. Example: the file system API: open, read, write, close hardware interface: keep track of where things are on disk allocate and reclaim move data from memory to disk and back Example: process management API: create new process, execute program hardware interface: allocate memory, PCB context switch between processes scheduling The API ------- The API is portable (to a greater or lesser degree) and often defined by standards (POSIX, JVM) It is usually more friendly (easier to use) than the hardware interface, by hiding lots of details, and performing lots of housekeeping tasks on your behalf. Example: in UNIX, all devices have the same interface! (hard disks, floppies, CD-ROMs, tapes, network interfaces, printers, keyboards, sound board) These are wildly different devices, with wildly different behaviors. It seems odd, at first glance, to shoehorn them all into the same interface. Hardware interface ------------------ In theory, the hardware interface is dictated by the hardware, but in practice the hardware and the OS co-evolve, which is why it is usually the case that there is only one OS for a given platform (although that is changing). Hardware interfaces, like device drivers, are generally not portable. For example, there are many ways the system might communicate with a device: serial and parallel port, bus, DMA. OS services ----------- Operating systems provide three kinds of services 1) libraries of common code, like I/O device drivers, but also math and other utilities that are not central to the OS 2) resource allocation: CPU, memory, disk space 3) resource coordination: printer and network collisions inter-process protection (Mac reliability vs. UNIX) History of OS ------------- 1.2 Batch systems OS shares physical memory with one process. Pro: simple Con: lots of idle time because loading is much slower than CPU 1.3 Multiprogramming OS shares physical memory with multiple processes. Pro: overlap I/O with CPU on coarse scale -- better CPU utilization Con: complications like interprocess protection 1.4 Time-sharing systems As computers get cheaper and people get more expensive, human utilization becomes more important than CPU utilization. Support interaction by multitasking -- switching between processes on a smaller time scale. Use virtual memory so the total demand can exceed the limits of physical memory. Pro: nifty Con: complicated 1.5 Single user systems Now computers are very cheap, humans very expensive. If each computer has a single user, We don't need multitasking, right? We don't need inter-process protection, right? We don't need virtual memory, right? WRONG! Need multitasking for responsiveness (not CPU utilization). Need protection for reliability and security. (for n components, interactions grow as n^2. How many inits does a typical Mac boot?) Need virtual memory to implement protection (not for performance). Problem: Hard to add these features as an afterthought. They need to be central to the design of the OS, and they need a little help from the hardware. The history of MacOS and Windows shows how hard it is to back into these features. But if you know how to do it, it's not that hard. The kernel of Linux was written by one person in six months. Reading for Tuesday: S&G Chapter 1 On page 20-21, prepare answers to questions 1.1, 1.5, 1.8, 1.11, 1.12