Introduction to Operating Systems:Operating System Architectures.

Operating System Architectures

Today’s operating systems tend to be complex because they provide many services and support a variety of hardware and software resources (see the Operating Systems Thinking feature, Keep It Simple (KIS) and the Anecdote,). Operating system architectures can help designers manage this complexity by organizing operating system components and specifying the privilege with which each component exe- cutes. In the monolithic design, every component of the operating system is contained in the kernel; in the microkernel design, only the essential components are included. In the sections that follow, we survey several important architectures (see the Operating Systems Thinking feature, Architecture).

Monolithic Architecture

The monolithic operating system is the earliest and most common operating system architecture. Every component of the operating system is contained in the kernel and can directly communicate with any other (i.e., simply by using function calls). The kernel typically executes with unrestricted access to the computer system (Fig. 1.3). OS/360, VMS and Linux are broadly characterized as monolithic operating systems.106 Direct intercommunication between components makes monolithic operating systems highly efficient. Because monolithic kernels group components together,

Operating Systems Thinking

Keep It Simple (KIS)

Complex systems are costly to design, implement, test, debug and maintain. Often, operating systems designers will choose the simplest of several approaches to solving a particular problem. Sometimes, though, a more complex approach can yield performance benefits or other improvements that make such an approach worthwhile. Such trade- offs are common in computing. A simple linear search of an array is trivial to program, but runs slowly compared to a more elegant and complicated binary search. Tree data structures can be more complex to work with than arrays, but make it easier and faster to per- form certain types of insertions and deletions. We typically con- sider alternate approaches to solving operating systems problems and developing resource management strategies. As you read these discussions, you will

see the trade-offs between simplicity and complexity. As you read these solutions, you might be inclined to favor certain approaches. The systems you work with in the future may demand different approaches. Our philosophy is to present the pros and cons of the popular approaches to help you prepare to make your own best judgment calls in industry.

however it is difficult to isolate the source of bugs and other errors. Further, because all code executes with unrestricted access to the system, systems with monolithic kernels are particularly susceptible to damage from errant or malicious code.

Self Review

1. What is the defining characteristic of a monolithic operating system?

2. Why do monolithic operating systems tend to be efficient? What is a key weakness of monolithic kernels?

Anecdote

System Architect vs. System Engineer

If you enter the field of operating systems development and you become more senior, you may be given a title like systems architect or systems engineer.A professional software colleague was a guest speaker at a conference

some years ago. He was introduced as a systems architect. He said: “You may wonder how that differs from being a systems engineer.” He humbly explained the difference with a building analogy: "When an engineer builds a building, it's very well built, but it's so ugly that the people tear it down; when an architect builds a building, it's very beautiful, but it falls down!" Lesson to operating systems designers: You need to combine aspects of both architecture and engineering to insure that your systems are both well built and elegant. The latter goal is less important.

Ans: 1) In a monolithic operating system every component of the operating system is contained in the kernel. 2) Monolithic kernels tend to be efficient because few calls cross from user space to kernel space. Because all OS code in monolithic kernels operates with unrestricted access to the computer’s hardware and software, these systems are particularly susceptible to damage from errant code.

Layered Architecture

As operating systems became larger and more complex, purely monolithic designs became unwieldy. The layered approach to operating systems attempts to address this issue by grouping components that perform similar functions into layers. Each layer communicates exclusively with those immediately above and below it. Lower- level layers provide services to higher-level ones using an interface that hides their implementation.

Layered operating systems are more modular than monolithic operating systems, because the implementation of each layer can be modified without requiring any modification to other layers.A modular system has self-contained componen that can be reused throughout the system. Each component hides how it performs

Operating Systems Thinking

Architecture

Just as architects use different approaches to designing build- ings, operating systems designers employ different architectural approaches to designing operating systems. Sometimes these approaches are pure in that one architectural approach is used throughout the system. Some- times hybridized approaches are used, mixing the advantages of several architectural styles. The approach the designer chooses will have monumental consequences on the initial implementation and the evolution of the operating system. It becomes

increasingly difficult to change approaches the further into the development you proceed, so it is important to choose the proper architecture early in system development. More generally, it is much easier to build the building correctly in the first place than it is to modify the building after it has been built.

One of the most common architectural approaches employed in software systems such as operating systems is called layering. This software is divided into modules called layers that each perform certain tasks. Each layer calls the services provided by the layer below it, while the implementation of that layer is hidden from the layer above. Layering combines the virtues of the soft- ware engineering techniques of modularity and information hiding to provide a solid basis for building quality systems. We discuss layered software approaches throughout the book, starting with a historic mention of Dijkstra's THE system (see Section 1.13.2, Layered Architecture) and continuing to explanations of how layering is used in Linux and Windows XP in Chapters 20, and 21, respectively.

its job and presents a standard interface that other components can use to request its services. Modularity imposes structure and consistency on the operating sys- tem—often simplifying validation, debugging and modification. However, in a layered approach, a user process’s request may need to pass through many layers before it is serviced. Because additional methods must be invoked to pass data from one layer to the next, performance degrades compared to that of a monolithic kernel, which may require only a single call to service a similar request. Also, because all layers have unrestricted access to the system, layered kernels are also susceptible to damage from errant or malicious code. The THE operating system is an early example of a layered operating system (Fig. 1.4).107 Many of today’s operating systems, including Windows XP and Linux, implement some level of layering.

Self Review

1. How are layered operating systems more modular than monolithic operating systems?

2. Why do layered operating systems tend to be less efficient than monolithic operating systems?

Ans:

1) In layered operating systems, the implementation and interface are separate for each layer. This allows each layer to be tested and debugged separately. It also enables designers to change each layer’s implementation without needing to modify the other layers.

2) In layered operating systems, several calls may be required to communicate between the layers, whereas this overhead does not exist in monolithic kernels.

Microkernel Architecture

A microkernel operating system architecture provides only a small number of services in an attempt to keep the kernel small and scalable. These services typically include low-level memory management, interprocess communication and basic pro-

cess synchronization to enable processes to cooperate. In microkernel designs, most operating system components—such as process management, networking, file sys- tem interaction and device management—execute outside the kernel with a lower privilege level (Fig. 1.5).108, 109, 110, 111 Microkernels exhibit a high degree of modularity, making them extensible, portable and scalable.112 Further, because the microkernel does not rely on each component to execute, one or more components can fail, without causing the operating system to fail. However, such modularity comes at the cost of an increased level of intermodule communication, which can degrade system performance. Although few of today’s popular operating systems fully embrace the microkernel design, Linux and Windows XP, for example, contain modular components.113

Self Review

1. What is the difference between a purely layered architecture and a microkernel architecture?

2. How do microkernels promote portability?

Ans:

1) A layered architecture enables communication exclusively between operating sys- tem components in adjacent layers. A microkernel architecture enables communication between all operating system components via the microkernel.

2) The microkernel does not depend on a particular hardware platform; support for new hardware can be provided by loading a new module.

Networked and Distributed Operating Systems

Advances in telecommunications technology have profoundly affected operating systems.A network operating system enables its processes to access resources (e.g., files) that reside on other independent computers on a network.114 The structure of many networked and distributed operating systems is often based on the client/server model (Fig. 1.6). The client computers in such a network request resources—such as files and processor time—via the appropriate network protocol. The servers respond with the appropriate resources. In such networks, operating system designers must carefully consider how to manage data and communication among computers.

Some operating systems are more “networked” than others. In a networked environment, a process can execute on the computer on which it is created or on another computer on the network. In some network operating systems, users can specify exactly where their processes run; in others, the operating system deter- mines where processes are executed. For example, the system may determine that a process can be more efficiently executed on a computer experiencing a light load.115 Networked file systems are an important component of networked operating systems. At the lowest level, users acquire resources on another machine by explicitly connecting to that machine and retrieving files. Higher-level network file systems enable users to access remote files as if they were on the local system. Examples of network file systems include Sun’s Network File System (NFS) and

CMU’s Andrew and Coda file systems. Networked file systems are discussed in detail in Chapter 18, Distributed Systems and Web Services.

A distributed operating system is a single operating system that manages resources on more than one computer system. Distributed systems provide the illusion that multiple computers are a single powerful computer, so that a process can access all of the system’s resources regardless of the process’s location within the distributed system’s network of computers.116 Distributed operating systems are often difficult to implement and require complicated algorithms to enable processes to communicate and share data. Examples of distributed operating systems are MIT’s Chord operating system and the Amoeba operating system from the Vrije Universiteit (VU) in Amsterdam.117, 118 We discuss distributed systems in Chapter 17, Introduction to Distributed Systems.

Now that we have presented a seemingly endless stream of facts, issues, and acronyms, we proceed with a discussion of the basic principles of computer hard- ware and software in Chapter 2, Hardware and Software Concepts.

Self Review

1. What is the major difference between networked and distributed operating systems?

2. What is the primary advantage of a distributed operating system? What is the primary challenge of designing one?

Ans: 1) A networked operating system controls one computer but cooperates with other computers on the network. In a distributed operating system, one operating system controls many computers in a network. 2) The primary advantage is that processes do not need to know the locations of the resources they use, which simplifies applications programming. This comes at the expense of the systems programmer, who must implement complicated algorithms to enable processes to communicate and share data among many computers, creating the illusion of there being only a single larger computer.

Web Resources

www.bell-labs.com/history/unix/ Provides a history of the UNIX operating system, from its origins in the Multics system to the mature UNIX operating systems of today. Discusses many of the design and architectural considerations in the evolution of UNIX.

www.softpanorama.org/History/os_history.shtml Provides a wealth of information on open-source software from a historical perspective.

www.microsoft.com/windows/WinHistoryIntro.mspx Provides a history of the Microsoft Windows family of operating systems.

www.viewz.com/shoppingguide/os.shtml Compares several popular operating systems, including Windows, Linux and MacOS, and provides a historical perspective.

developer.apple.com/darwin/history.html Covers the evolution of Darwin, the core of Apple’s OS X operating system.

www.cryptonomicon.com/beginning.html

Contains a link to the article, “In the Beginning Was the Command Line,” by Neal Stephenson. This text is a narrative account of the recent history of operating systems, making colorful use of anecdote and metaphor.

www.acm.org/sigcse/cc2001/225.html

Lists the operating systems course curriculum recommendation from the ACM/IEEE Joint Task Force that completed the Computing Curricula 2001 (CC2001) project. The curriculum indicates key areas of coverage for a typical operating systems course.

whatis.techtarget.com/

Provides definitions for computer-related terms.

www.webopedia.com/

Provides an online dictionary and a search engine for com- puter- and Internet-related terms.