Download Operating Systems I: Lecture Notes on Operating System Structures and Services and more Summaries Operating Systems in PDF only on Docsity!
1 System Structures
An operating system provides the environment within which programs are executed. OSs are organized along many different lines. These goals form the basis for choices among various algorithms and strategies. We can view an operating system from several points. One view focuses on the services that the system provides; another, on the interface that it makes available to users and programmers; a third, on its components and their interconnections. Table of Contents 1 System Structures ................................................................................................................. 1 1.1 Operating-System Services ............................................................................................................ 2 1.2 User Operating-System Interface .................................................................................................. 3 1.2.1 Command Interpreter ................................................................................................................ 3 1.2.2 Graphical User Interfaces ........................................................................................................... 3 1.3 System Calls .................................................................................................................................. 3 1.3.1 Types of System Calls ................................................................................................................. 4 1.3.2 Process Control .......................................................................................................................... 4 1.3.3 File Management ....................................................................................................................... 6 1.3.4 Device Management .................................................................................................................. 6 1.3.5 Information Maintenance .......................................................................................................... 7 1.3.6 Communication .......................................................................................................................... 7 1.3.7 Protection .................................................................................................................................. 8 1.4 System Programs .......................................................................................................................... 8 1.5 Operating-System Design and Implementation ............................................................................. 9 1.5.1 Design Goals ............................................................................................................................... 9 1.5.2 Mechanisms and Policies ......................................................................................................... 10 1.5.3 Implementation ....................................................................................................................... 10 1.6 Operating-System Structure ........................................................................................................ 10 1.6.1 Simple Structure ...................................................................................................................... 10 1.6.2 Layered Approach .................................................................................................................... 11
1.6.3 Microkernels ............................................................................................................................ 14 1.6.4 Modules ................................................................................................................................... 14 1.7 Summary .................................................................................................................................... 15 CHAPTER OBJECTIVES
- To describe the services an operating system provides to users, processes, and other systems.
- To discuss the various ways of structuring an operating system.
- To explain how operating systems are installed and how they boot. 1.1 Operating-System Services An operating system provides an environment for the execution of programs. It provides certain services to programs and to the users of those programs. The specific services provided, of course, differ from one operating system to another, but we can identify common classes. These operating-system services are provided for the convenience of the programmer, to make the programming task easier. Figure 2.1 A view of operating-system services. Figure 2.1 shows one view of the various operating-system services and how they interrelate. 50 Chapter 2 Operating-System Structures user and other system programs services operating system hardware system calls GUI batch user interfaces command line program execution I/O operations file systems communication^ resource allocation accounting protection and security error detection Figure 2.1 A view of operating-system services. task easier. Figure 2.1 shows one view of the various operating-system services and how they interrelate. One set of operating-system services provides functions that are helpful to the user.
- User interface. Almost all operating systems have a^ user interface (UI). This interface can take several forms. One is a command-line interface (CLI) , which uses text commands and a method for entering them (say, a program to allow entering and editing of commands). Another is a batch interface , in which commands and directives to control those commands are entered into files, and those files are executed. Most commonly, a
1.3.1 Types of System Calls System calls can be grouped roughly into six major categories: process control , file manipulation , device manipulation , information maintenance , communications , and protection. 1.3.2 Process Control A running program needs to be able to halt its execution either normally (end) or abnormally (abort). If a system call is made to terminate the currently running program abnormally, or if the program runs into a problem and causes an error trap, a dump of memory is sometimes taken and an error message generated. The dump is written to disk and may be examined by a debugger — a system program designed to aid the programmer in finding and correcting bugs—to determine the cause of the problem. Under either normal or abnormal circumstances, the operating system must transfer control to the invoking command interpreter. The command interpreter then reads the next command. In an interactive system, the command interpreter simply continues with the next command; it is assumed that the user will issue an appropriate command to respond to any error. In a GUI system, a pop-up window might alert the user to the error and ask for guidance.
- Process^ control^ ◦^ end, abort ◦ (^) load, execute ◦ (^) create process, terminate process ◦ (^) get process attributes, set process attributes ◦ (^) wait for time ◦^ wait event, signal event ◦^ allocate and free memory
- File^ management^ ◦^ create file, delete file ◦ (^) open, close ◦ (^) read, write, reposition ◦ (^) get file attributes, set file attributes
- Device^ management^ ◦^ request device, release device ◦ (^) read, write, reposition ◦ (^) get device attributes, set device attributes ◦ (^) logically attach or detach devices
- Information^ maintenance^ ◦^ get time or date, set time or date ◦ (^) get system data, set system data ◦ (^) get process, file, or device attributes ◦ (^) set process, file, or device attributes
- Communications^ ◦^ create, delete communication connection ◦ (^) send, receive messages ◦ (^) transfer status information ◦ (^) attach or detach remote devices The MS-DOS operating system is an example of a single-tasking system. It has a command interpreter that is invoked when the computer is started (Figure 2.10a). Because MS-DOS is single-tasking, it uses a simple method to run a program and does not create a new process. Figure 2.10 MS-DOS execution. (a) At system startup. (b) Running a program. It loads the program into memory, writing over most of itself to give the program as much memory as possible (Figure 2.10b). Next, it sets the instruction pointer to the first instruction of the program. The program then runs, and either an error causes a trap, or the program executes a system call to terminate. FreeBSD (derived from Berkeley UNIX) is an example of a multitasking system. When a user logs on to the system, the shell of the user’s choice is run. This shell is similar to the MS-DOS shell in that it accepts commands and executes programs that the user requests. However, since FreeBSD is a multitasking system, the command interpreter may continue running while another program is executed (Figure 2.11). To start a new process. 2.4 Types of System Calls 63 (a) (b) free memory command interpreter kernel process free memory command interpreter kernel Figure 2.10 MS-DOS execution. (a) At system startup. (b) Running a program. new process. It loads the program into memory, writing over most of itself to give the program as much memory as possible (Figure 2.10b). Next, it sets the instruction pointer to the first instruction of the program. The program then runs, and either an error causes a trap, or the program executes a system call to terminate. In either case, the error code is saved in the system memory for later use. Following this action, the small portion of the command interpreter that was not overwritten resumes execution. Its first task is to reload the rest of the command interpreter from disk. Then the command interpreter makes the previous error code available to the user or to the next program. FreeBSD (derived from Berkeley UNIX) is an example of a multitasking system. When a user logs on to the system, the shell of the user’s choice is run. This shell is similar to the MS-DOS shell in that it accepts commands and executes programs that the user requests. However, since FreeBSD is a multitasking system, the command interpreter may continue running while another program is executed (Figure 2.11). To start a new process, the shell free memory interpreter kernel process D process C process B Figure 2.11 FreeBSD running multiple programs.
1.3.5 Information Maintenance Many system calls exist simply for the purpose of transferring information between the user program and the operating system. For example, most systems have a system call to return the current time and date. Other system calls may return information about the system, such as the number of current users, the version number of the operating system, the amount of free memory or disk space, and so on. Another set of system calls is helpful in debugging a program. Many systems provide system calls to dump memory. This provision is useful for debugging. A program trace lists each system call as it is executed.. 1.3.6 Communication There are two common models of interprocess communication: the message- passing model and the shared-memory model. In the message-passing model , the communicating processes exchange messages with one another to transfer information. Messages can be exchanged between the processes either directly or indirectly through a common mailbox. Before communication can take place, a connection must be opened. The name of the other communicator must be known, be it another process on the same system or a process on another computer connected by a communications network. In the shared-memory model , processes use shared memory create and shared memory attach system calls to create and gain access to regions of memory owned by other processes. Recall that, normally, the operating system tries to prevent one process from accessing another process’s memory. Shared memory requires that two or more processes agree to remove this restriction. They can then exchange information by reading and writing data in the shared areas. The form of the data is determined by the processes and is not under the operating system’s control. The processes are also responsible for ensuring that they are not writing to the same location simultaneously.
1.3.7 Protection Protection provides a mechanism for controlling access to a computer system’s resources. 1.4 System Programs Another aspect of a modern system is the collection of system programs. Recall Figure 1.1, which depicts the logical computer hierarchy. At the lowest level is hardware. Next is the operating system, then the system programs, and finally the application programs. System programs , also known as system utilities , provide a convenient environment for program development and execution. Some of them are simply user interfaces to system calls; others are considerably more complex. They can be divided into these categories:
- File management. These programs create, delete, copy, rename, print, dump, list, and generally manipulate files and directories.
- Status information. Some programs simply ask the system for the date, time, amount of available memory or disk space, number of users, or similar status information. Others are more complex, providing detailed performance, logging, and debugging information. Typically, these programs format and print the output to the terminal or other output devices or files or display it in a window of the GUI.
- File modification. Several text editors may be available to create and modify the content of files stored on disk or other storage devices.
- Programming-language support. Compilers, assemblers, debuggers, and interpreters for common programming languages (such as C, C++, Java, Visual Basic, and PERL) are often provided to the user with the operating system.
- Program loading and execution. Once a program is assembled or compiled, it must
Users want certain obvious properties in a system. The system should be convenient to use, easy to learn and to use, reliable, safe, and fast. Of course, these specifications are not particularly useful in the system design, since there is no general agreement on how to achieve them. A similar set of requirements can be defined by those people who must design, create, maintain, and operate the system. The system should be easy to design, implement, and maintain; and it should be flexible, reliable, error free, and efficient. 1.5.2 Mechanisms and Policies 1.5.3 Implementation Once an operating system is designed, it must be implemented. Traditionally, operating systems have been written in assembly language. Now, however, they are most commonly written in a higher-level language such as C or C++. The advantages of using a higher-level language, or at least a systems- implementation language, for implementing operating systems are the same as those accrued when the language is used for application programs: the code can be written faster, is more compact, and is easier to understand and debug. In addition, improvements in compiler technology will improve the generated code for the entire operating system by simple recompilation. 1.6 Operating-System Structure A system as large and complex as a modern operating system must be engineered carefully. A common approach is to partition the task into small components rather than have one monolithic system. Each of these modules should be a well-defined portion of the system, with carefully defined inputs, outputs, and functions. 1.6.1 Simple Structure Many commercial operating systems do not have well-defined structures. Frequently, such systems started as small, simple, and limited systems and then grew beyond their
Oper ating Systems I- Lectur e Lectur er : Dr. Sur a Z. Alr ashid original scope. MS-DOS is an example of such a system. It was originally designed and implemented by a few people who had no idea that it would become so popular. It was written to provide the most functionality in the least space, so it was not divided into modules carefully. Figure 2.12 shows its structure. Figure 2.12 MS-DOS layer structure. Figure 2.13 Traditional UNIX system structure. 1.6.2 Layered Approach With proper hardware support, operating systems can be broken into pieces that are smaller and more appropriate than those allowed by the original MS-DOS and UNIX systems. The operating system can then retain much greater control over the computer 2.7 Operating-System Structure 71 ROM BIOS device drivers application program MS-DOS device drivers resident system program Figure 2.12 MS-DOS layer structure. when user programs fail. Of course, MS-DOS was also limited by the hardware of its era. Because the Intel 8088 for which it was written provides no dual mode and no hardware protection, the designers of MS-DOS had no choice but to leave the base hardware accessible. Another example of limited structuring is the original UNIX operating system. Like MS-DOS, UNIX initially was limited by hardware functionality. It consists of two separable parts: the kernel and the system programs. The kernel is further separated into a series of interfaces and device drivers, which have been added and expanded over the years as UNIX has evolved. We can view the traditional UNIX operating system as being layered, as shown in Figure 2.13. Everything below the system-call interface and above the physical hardware is the kernel. The kernel provides the file system, CPU scheduling, memory kernel (the users) shells and commands compilers and interpreters system libraries system-call interface to the kernel signals terminal handling character I/O system terminal drivers file system swapping block I/O system disk and tape drivers CPU scheduling page replacement demand paging virtual memory kernel interface to the hardware terminal controllers terminals device controllers disks and tapes memory controllers physical memory Figure 2.13 Traditional UNIX system structure. 2.7 Operating-System Structure 71 ROM BIOS device drivers application program MS-DOS device drivers resident system program Figure 2.12 MS-DOS layer structure. when user programs fail. Of course, MS-DOS was also limited by the hardware of its era. Because the Intel 8088 for which it was written provides no dual mode and no hardware protection, the designers of MS-DOS had no choice but to leave the base hardware accessible. Another example of limited structuring is the original UNIX operating system. Like MS-DOS, UNIX initially was limited by hardware functionality. It consists of two separable parts: the kernel and the system programs. The kernel is further separated into a series of interfaces and device drivers, which have been added and expanded over the years as UNIX has evolved. We can view the traditional UNIX operating system as being layered, as shown in Figure 2.13. Everything below the system-call interface and above the physical hardware is the kernel. The kernel provides the file system, CPU scheduling, memory kernel (the users) shells and commands compilers and interpreters system libraries system-call interface to the kernel signals terminal handling character I/O system terminal drivers file system swapping block I/O system disk and tape drivers CPU scheduling page replacement demand paging virtual memory kernel interface to the hardware terminal controllers terminals device controllers disks and tapes memory controllers physical memory Figure 2.13 Traditional UNIX system structure.
correct) to implement its functions. Once the first layer is debugged, its correct functioning can be assumed while the second layer is debugged, and so on. If an error is found during the debugging of a particular layer, the error must be on that layer, because the layers below it are already debugged. Thus, the design and implementation of the system are simplified. Each layer is implemented with only those operations provided by lower- level layers. A layer does not need to know how these operations are implemented; it needs to know only what these operations do. Hence, each layer hides the existence of certain data structures, operations, and hardware from higher-level layers. The major difficulty with the layered approach involves appropriately defining the various layers. Because a layer can use only lower-level layers, careful planning is necessary. For example, the device driver for the backing store (disk space used by virtual-memory algorithms) must be at a lower level than the memory-management routines, because memory management requires the ability to use the backing store. Other requirements may not be so obvious. The backing-store driver would normally be above the CPU scheduler, because the driver may need to wait for I/O and the CPU can be rescheduled during this time. However, on a large system, the CPU scheduler may have more information about all the active processes than can fit in memory. Therefore, this information may need to be swapped in and out of memory, requiring the backing- store driver routine to be below the CPU scheduler. A final problem with layered implementations is that they tend to be less efficient than other types. For instance, when a user program executes an I/O operation, it executes a system call that is trapped to the I/O layer, which calls the memory-management layer, which in turn calls the CPU-scheduling layer, which is then passed to the hardware. At each layer, the parameters may be modified, data may need to be passed, and so on. Each layer adds overhead to the system call; the net result is a system call that takes longer than does one on a nonlayered system.
These limitations have caused a small backlash against layering in recent years. Fewer layers with more functionality are being designed, providing most of the advantages of modularized code while avoiding the difficult problems of layer definition and interaction. 1.6.3 Microkernels This method structures the operating system by removing all nonessential components from the kernel and implementing them as system and user-level programs. The result is a smaller kernel. Typically, microkernels provide minimal process and memory management, in addition to a communication facility. The main function of the microkernel is to provide a communication facility between the client program and the various services that are also running in user space. Communication is provided by message passing, For example, if the client program wishes to access a file, it must interact with the file server. The client program and service never interact directly. Rather, they communicate indirectly by exchanging messages with the microkernel. 1.6.4 Modules Perhaps the best current methodology for operating-system design involves using object-oriented programming techniques to create a modular kernel. Here, the kernel has a set of core components and links in additional services either during boot time or during run time. Such a strategy uses dynamically loadable modules and is common in modern implementations of UNIX, such as Solaris, Linux, and Mac OS X. For example, the Solaris operating system structure, shown in Figure 2.15, is organized around a core kernel with seven types of loadable kernel modules:
- Scheduling classes
- File systems
- Loadable system calls
- Executable formats
- STREAMS modules
The design of a new operating system is a major task. It is important that the goals of the system be well defined before the design begins. The type of system desired is the foundation for choices among various algorithms and strategies that will be needed. Since an operating system is large, modularity is important. Designing a system as a sequence of layers or using a microkernel is considered a good technique. The virtual- machine concept takes the layered approach and treats both the kernel of the operating system and the hardware as though they were hardware. Even other operating systems may be loaded on top of this virtual machine. Throughout the entire operating-system design cycle, we must be careful to separate policy decisions from implementation details (mechanisms). This separation allows maximum flexibility if policy decisions are to be changed later. Operating systems are now almost always written in a systems- implementation language or in a higher-level language. This feature improves their implementation, maintenance, and portability. To create an operating system for a particular machine configuration, we must perform system generation. Debugging process and kernel failures can be accomplished through the use of debuggers and other tools that analyze core dumps. Tools such as DTrace analyze production systems to find bottlenecks and understand other system behavior. For a computer system to begin running, the CPU must initialize and start executing the bootstrap program in firmware. The bootstrap can execute the operating system directly if the operating system is also in the firmware, or it can complete a sequence in which it loads progressively smarter programs from firmware and disk until the operating system itself is loaded into memory and executed.
