Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Gary Kimura Lecture #3 October 4, 2002 CSE451 Operating Systems Components and Basic Organization Autumn 2002.

Similar presentations


Presentation on theme: "1 Gary Kimura Lecture #3 October 4, 2002 CSE451 Operating Systems Components and Basic Organization Autumn 2002."— Presentation transcript:

1 1 Gary Kimura Lecture #3 October 4, 2002 CSE451 Operating Systems Components and Basic Organization Autumn 2002

2 2 Today We already talked about the purpose of an OS The hardware support for an OS Now we’re going to take the 60,000 foot view of an OS But first a clarification infinite user loops and referencing kernel objects in user mode, A brief comment about rocket science, OS evolution and what we cover in class

3 3 OS Structure To understand an OS, let’s first look at its components and then how they’re composed or organized. We’ll come back and look at each of these in detail as the course progresses. Realize that it’s never as simple as it looks. These basic concepts exist in some form in all systems, however each system implements them in a slightly different way. Also, the divisions between components may not be as clean in the real world as in the model A useful taxonomy –modules: the major OS services and abstractions –interfaces: specific operations that modules provide –structure: the way the modules are stitched together

4 4 Major OS components processes memory I/O secondary storage file systems protection accounting shells (command interpreter, or OS UI)

5 5 Process Management An operating system executes many kinds of activities: –user programs –batch jobs or command scripts –system programs: print spoolers, name servers, file servers, network listeners, etc... Each of these “execution entities” is encapsulated in a process. The process includes the execution context (pc, registers, vm, resources, etc) and all info the activity (program) needs to run. The OS schedules processes to run.

6 6 Processes A program is a passive thing -- just a file on the disk with code that is potentially runnable. A process is one instance of a program in execution; At any instance, there may be many processes running copies of a single program (e.g., an editor): each is a separate, independent process. Code Stack PC Registers page tables resource counts.... Code Stack PC Registers page tables resource counts.... Process B Process A

7 7 Process Operations Processes are fundamental OS-provided objects. The OS supports operations on processes, e.g.: –create a process –delete a process –suspend a process –resume a process –inter-process communication –inter-process synchronization –create/delete a subprocess

8 8 Memory management The primary memory (or RAM) is the directly accessed storage for the CPU –programs must be stored in memory to execute –memory access is fast (e.g. 60 ns to load/store) but memory doesn’t survive power failures OS must: –allocate memory space for programs (explicitly and implicitly) –deallocate space when needed by rest of system –maintain mappings from physical to virtual memory through page tables –decide how much memory to allocate to each process a policy decision –decide when to remove a process from memory also policy

9 9 I/O A big chunk of the OS kernel deals with I/O –hundreds of thousands of lines in NT The OS provides a standard interface between programs (user or system) and devices –file system (disk), sockets (network), frame buffer (video) Device drivers are the routines that interact with specific device types –encapsulates device-specific knowledge –e.g., how to initialize a device, how to request I/O, how to handle interrupts or errors –examples: SCSI device drivers, Ethernet card drivers, video card drivers, sound card drivers, …

10 10 Secondary Storage Secondary storage (disk, tape) is persistent memory –often magnetic media, survives power failures (hopefully) Routines that interact with disks are typically at a very low level in the OS –used by many components (file system, VM, …) –handle scheduling of disk operations, head movement, error handling, and often management of space on disks Usually independent of file system –although there may be cooperation –file system knowledge of device details can help optimize performance e.g. place related files close together on disk

11 11 File Systems Secondary storage devices are crude and awkward –e.g. “write 4096 byte block to sector 12” File system: a convenient abstraction –defines logical objects like files and directories hides details about where on disk files live –as well as operations on objects like read and write read/write byte ranges instead of blocks A file is the basic long-term storage unit –file = named collection of persistent information A directory is just a special kind of file –directory = named file that contains names of other files and metadata about those files (e.g. file size)

12 12 File system operations The file system interface defines standard operations: –file (or directory) creation and deletion –manipulation of files and directories (read, write, extend, rename, protect) –copy –lock File systems also provide higher level services –accounting and quotas –backup –(sometimes) indexing or search –(sometimes) file versioning

13 13 Protection System protection is a general mechanism throughout the OS all resources objects need protection –memory –processes –files –devices protection mechanisms help to detect errors as well as to prevent malicious destruction

14 14 Command Interpreter (shell) a particular program that handles the interpretation of users’ commands and helps to manage processes –user input may be from keyboard (command-line interface), from script files, or from the mouse (GUIs) –allows users to launch and control new programs on some systems, command interpreter may be a standard part of the OS (e.g. MSDOS, Apple II) on others, it’s just a non-privileged process that provides an interface to the user –e.g. bash/csh/tcsh/zsh on UNIX on others, there may be no command language –e.g. MacOS

15 15 Accounting Keeps track of resource usage –both to enforce quotas “you’re over your disk space limit” –or to produce bills important for timeshared computers like mainframes

16 16 OS Structure Hardware Memory Management I/O System Secondary Storage Management File System Protection System Accounting System Process Management Command Interpreter Information Services The OS (a simplified view) Error Handling

17 17 OS Structure (Continued) An OS consists of all of these components, plus lots of others, plus system service routines, plus system programs (privileged and non-privileged), plus.... The big issue: –how do we organize all of this? –what are the entities and where do they exist? –how does these entities cooperate? Basically, how do we build a complex system that’s: –performant –reliable –extensible

18 18 Monolithic Structure Traditionally, systems such as Unix were built as a monolithic kernel: hardware OS kernel user programs everything file system, virtual memory, I/O drivers, process control, system services, swapping, networks, protection, interrupt handling, windows, accounting,...

19 19 Monolithic Structure (Continued) Problems with monolithic kernels: –hard to understand –hard to modify –unreliable: a bug anywhere causes a system crash –hard to maintain Since the beginnings of OS design, people have sought ways to organize the OS to simplify its design and construction.

20 20 Structuring Traditional approach is layering: implement system as a set of layers, where each layer is a virtual machine to the layer above. That is, each layer provides a “machine” that has higher level features. hardware layer 0 layer 1 layer 2 layer 3 hardware arch. interface layer 1 interface

21 21 Layering in THE The first description of this approach was Dijkstra’s THE system. hardware CPU scheduling (processes) memory management console device (commands) I/O device buffering user programs

22 22 THE System System was composed as a set of sequential processes. Each performs a sequential computation. Processes communicate through explicit synchronization statements. Each process could be tested and verified independently. Each level sees a logical machine provided by lower levels. –level 2 sees virtual processors –level 3 sees VM (really segments) –level 4 sees a “virtual console” –level 5 sees “virtual” I/O drivers The preceding is presented to give a historical perspective on modern OS evolution

23 23 Problems with Layering Systems must be hierarchical, but real systems are more complex than that, e.g., –file system would like to be a process layered on VM –VM would like to use files for its backing store I/O Approach is not flexible. Often has poor performance due to layer crossings. Systems are often modeled as layered structures but not built that way (for better or worse).

24 24 Microkernel Approach The organizing structure currently in vogue is the microkernel OS. Goal is minimize what goes in the kernel, and implement much of the OS as user-level processes. This results in: –better reliability –ease of extension and customization –mediocre performance (unfortunately) First microkernel system was Hydra (CMU, 1970) Examples of microkernel systems are the CMU Mach system, Chorus (French Unix-like system), and in some circles Microsoft Windows NT/2000 is called microkernel like. But not I.

25 25 Microkernel System Structure hardware microkernel low-level VM protection processor control system processes file system thread system communication external paging network support high-level scheduling user processes kernel mode user mode

26 26 Summary and Next Time Summary –OS design has been a evolutionary process of trial and error. Probably more error than success –Successful OS’s designs have run the spectrum from monolithic, to layered, to micro kernels, to virtual machines –The role and design of an OS is still evolving –It is impossible to pick one “correct” way to structure an OS Next Time –Processes, one of the most fundamental pieces in an OS –What is a process, what does it do, and how does it do it


Download ppt "1 Gary Kimura Lecture #3 October 4, 2002 CSE451 Operating Systems Components and Basic Organization Autumn 2002."

Similar presentations


Ads by Google