Reflections on an operating system design

An operating system mediates among application programs, utilities, and users, on the one hand, and the computer system hardware on the other. To appreciate the functionality of the operating system and the design issues involved, one must have some appreciation for computer organization and architecture. Chapter 1 provides a brief survey of the processor, memory, and Input/Output (I/O) elements of a computer system. The topic of operating system (OS) design covers a huge territory, and it is easy to get lost in the details and lose the context of a discussion of a particular issue. Chapter 2 provides an overview to which the reader can return at any point in the book for context. We begin with a statement of the objectives and functions of an operating system. Then some historically important systems and OS functions are described. This discussion allows us to present some fundamental OS design principles in a simple environment so that the relationship among various OS functions is clear. The chapter next highlights important characteristics of modern operating systems. Throughout the book, as various topics are discussed, it is necessary to talk about both fundamental, well-established principles as well as more recent innovations in OS design. The discussion in this chapter alerts the reader to this blend of established and recent design approaches that must be addressed. Finally, we present an overview of Windows, UNIX, and Linux; this discussion establishes the general architecture of these systems, providing context for the detailed discussions to follow.

Operating System, 2019

Software: Practice and Experience, 1989

Elmwood is an object-oriented, multiprocessor operating system designed and implemented during a graduate seminar. It consists of a minimal kernel and a collection of user-implemented services. The kernel provides two major abstractions: objects, which consist of code and data, and processes, which represent asynchronous activity. Objects, like programs, are passive. To operate on an abstraction or to request a service, processes invoke an entry procedure defined by the corresponding object. Objects implement their own protection and synchronization policies using minimal kernel mechanisms. We describe the Elmwood kernel interface, an implementation on the BBN Butterfly parallel processor, and our experiences in developing a multiprocessor operating system under rigid time constraints. These experiences illustrate several general lessons regarding kernel design and trade-offs for implementation expedience.

Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133), 1997

We believe it is time to reexamine the operating system's role in computing. Operating systems exist to create an environment in which compelling applications come to life. They do that by providing abstractions built on the services provided by hardware. We argue that advances in hardware and networking technology enable a new kind of operating system to support tomorrow's applications. Such an operating system would raise the level of abstraction for developers and users, so that individual computers, file systems, and networks become unimportant to most computations in the same way that processor registers, disk sectors, and physical pages are today.

1986

Which page should be swapped out? 114 Startup-phase conflicts. 115 Perspective 116 Further reading 118 Exercises 118 Chapter 4 RESOURCE DEADLOCK 121 Nuts and bolts 122 Deadlock and starvation 124 Dining philosophers 128 One-shot allocation 131 Hierarchical allocation 132 Advance-claim algorithm 133 Deadlock detection 138 Deadlock recovery 141 Starvation 141 Perspective 142 Further reading 144 Exercises 144 Chapter 5 TRANSPUT 147 Device hardware 148 1.1 Disks 148 Contents vii 2.2 Virtual interrupts 297 2.3 Pipes 298 2.4 Ports 301 Data. Access. 302 Naming and transfer. 303 2.5 Semantics of Read and Write 307 3 Distributed operating systems 308 3.1 Multiprocessors 308 3.2 Local-area networks 309 3.3 Long-haul networks 311 3.4 Multicomputers 312 4 The communication-kernel approach 313 4.1 Processes and threads 314 4.2 Communication 315 4.3 Space management 316 4.4 Other services 316 5 Perspective 317 6 Further reading 318 7 Exercises 319 REFERENCES 322 GLOSSARY 328 INDEX 352 viii Contents Balance is a registered trademark of Sequent Computer Systems, Inc. CMS is a registered trademark of IBM. CP/M is a registered trademark of Digital Research. Cray-1 is a registered trademark of Cray Research. Cray-2 is a registered trademark of Cray Research. Cyber is a registered trademark of Control Data Corporation. DEC is a registered trademark of Digital Equipment Corporation. DECnet is a registered trademark of Digital Equipment Corporation. Dynix is a registered trademark of Sequent Computer Systems, Inc. Exec-8 is a registered trademark of Sperry Rand. IBM is a registered trademark of International Business Machines Corporation. Locus is a registered trademark of Locus Computing Corporation. MS-DOS is a registered trademark of Microsoft Corporation. MVS is a registered trademark of IBM. NonStop is a registered trademark of Tandem Computers. OS/360 is a registered trademark of IBM. PDP-10 is a registered trademark of Digital Equipment Corporation. PDP-11 is a registered trademark of Digital Equipment Corporation. RT-11 is a registered trademark of Digital Equipment Corporation. Tenex is a registered trademark of BBN. Tops-10 is a registered trademark of Digital Equipment Corporation. Tops-20 is a registered trademark of Digital Equipment Corporation. Univac is a registered trademark of Sperry Rand. Unix is a registered trademark of Bell Laboratories. VAX is a registered trademark of Digital Equipment Corporation. VM/370 is a registered trademark of IBM. VMS is a registered trademark of Digital Equipment Corporation. Contents ix PREFACE Traditionally, a vade mecum (pronounced ''VAHdee MAYkem'') is a laboratory manual that guides the student step by step through complex procedures. Operating systems are complex mixtures of policy and mechanism, of algorithm and heuristic, and of theoretical goals and practical experience. This vade mecum tries to unify these diverse points of view and guide the novice step by step through the complexities of the subject. As a text, this book is intended for a first course in operating systems at the undergraduate level. The subject has so many individual parts that its practitioners and teachers often concentrate on subareas and ignore the larger concepts that govern the entire subject. I have tried to rectify that situation in this book by structuring the presentation about the dual ideas of resource management and beautification. To unify disparate threads of discussion, I have taken the liberty introducing names for recurrent themes and glorifying them with the title ''principles.'' I hope that this organization and nomenclature will help the reader to understand the subject better and to integrate new ideas into the same framework. Each technical term that is introduced in the text is printed in boldface the first time it appears. All boldface entries are collected and defined in the glossary. I have striven to use a consistent nomenclature throughout the book. At times this nomenclature is at odds with accepted American practice. For example, I prefer to call computer memory ''store.'' This name allows me to unify the various levels of the storage hierarchy, including registers, main store, swap space, files on disk, and files on magnetic tape. I also prefer the single word ''transput'' to the clumsier but more common term ''input/output.'' Although I found this term jarring at first, I have grown to like it. Each chapter closes with a section on perspective, suggestions for further reading, and exercises. The perspective section steps back from the details of the subject and summarizes the choices that actual operating systems have made and rules of thumb for distinguishing alternatives. It also fits the subject of the chapter into the larger picture. The suggestions for further reading have two purposes. First, they show the reader where more information on the subject discussed in the chapter may be found. Second, they point to research articles related to the subject that describe actual implementations and xi areas of current activity. The exercises also serve two purposes. First, they allow the student to test his or her understanding of the subject presented in the text by working exercises directly related to the material. More importantly, they push the student beyond the confines of the material presented to consider new situations and to evaluate new policies. Subjects that are only hinted at in the text are developed more thoroughly in this latter type of exercise. A course in operating systems is not complete without computer projects. Unfortunately, such exercises require a substantial investment in software. The most successful projects for a first course in operating systems involve implementing parts of an operating system. A complete operating system can be presented to the class, with welldefined modules and interfaces, and the class can be assigned the task of replacing modules with ones of their own design. A less ambitious project has the students first build a simple scheduler for a simulated machine. After it is completed, it can be enhanced by adding virtual memory, transput, and other features. If the necessary software is not available for these assignments, students can be asked to simulate particular policies or algorithms in isolation from a complete operating system. Several exercises in the book give guidelines for this sort of project. This second edition of the text differs from the first in several ways. Many figures have been added, both to clarify individual points and to unify the treatment of different subjects with similar diagrams. For example, the history of operating system styles is now adorned with consistent pictures. The nuts and bolts of process switching has been moved from Chapter 2 to Chapter 1, and a new section on virtual-machine operating systems has been added. The discussion of page-replacement policies in Chapter 2 has been enhanced with fault-rate graphs drawn from a simulation. Analysis and simulation are described near the end of Chapter 2. Chapter 9 on cooperating processes has been enlarged with a major new section on the communication-kernel approach. The Hysteresis Principle has been introduced. Minor errors and inconsistencies have been fixed throughout the text. I owe a debt of gratitude to the many people who helped me write this text. The students of Bart Miller's operating system class all wrote book reviews for an early draft. My parents Asher and Miriam and my brothers Joel and Barry devoted countless hours to a careful reading of the entire text, suggesting clarifications and rewording throughout. My colleagues Bart Miller, Mary Vernon, and Michael Carey read and criticized individual chapters. Michael Scott's careful reading of Chapter 8 and his keen insight into language issues in general were of great help. I am also grateful to

Fundamental concepts are introduced in simple terms. • The associations between techniques and concepts are readily established. • Numerous examples are included to illustrate concepts and techniques. • Implementation details and case studies are organized as small capsules spread throughout the text. xvi Preface xvii • Optional sections are devoted to advanced topics such as deadlock characterization, kernel memory allocation, synchronization and scheduling in multiprocessor systems, file sharing semantics, and file system reliability. The key benefit of this approach is that concepts, techniques, and case studies are well integrated, so many design and implementation details look "obvious" by the time the reader encounters them. It emphasizes the most important message an operating systems text can give to students: A concept-based study of operating systems equips a computer professional to comprehend diverse operating system techniques readily. • Preview of the Book The last section of the first chapter is a brief preview of the book that motivates study of each chapter by describing its importance within the overall scheme of the operating system, the topics covered in the chapter, and its relationships with other chapters of the book. xviii Preface and Windows, respectively, except when features of a specific version such as Linux 2.6 or Windows Vista are being discussed. Tests of Concepts A set of objective and multiple-choice questions is provided at the end of each chapter so that the reader can test his grasp of concepts presented in the chapter. Exercises Exercises are included at the end of each chapter. These include numerical problems based on material covered in the text, as well as challenging conceptual questions that test understanding and also provide deeper insights.

2012

Computers are a very important part of our lives and the major reason why they have been such a success is because of the excellent graphical operating systems that run on these powerful machines. As the computer hardware is becoming more and more powerful, it is also vital to keep the software updated in order to utilize the hardware of the system efficiently and make it faster and smarter. This paper highlights some core issues that if dealt with in the operating system level would make use of the full potential of the computer hardware and provide an excellent user experience.

Existing operating system (OS) designs provide inadequate isolation of user applications from errors that occur in OS services. If an error causes the failure of an OS service, all dependent applications are affected. The OS design described in this paper ameliorates this problem by reorganizing OS state in an effort to make OS services transparently restartable. This is achieved by partitioning application-related OS state into isolated per-application memory regions. Access to these memory regions is provided to OS services on a "need-to-know" basis when processing application requests. Applications are not allowed access to these memory regions for security. This design helps improve the dependability of the system.

Software: Practice and Experience, 1998

Single-address-space operating systems (SASOS) are an attractive model for making the best use of the wide address space provided by the latest generations of microprocessors. SASOS remove the address space borders which make data sharing between processes dicult and expensive in traditional operating systems. This o ers the potential of signi cant performance advantages for applications where sharing is important, such as object-oriented databases or persistent programming systems.