A paged - operating - system project
Jorge Eggli1984, ACM SIGCSE Bulletin
Sign up for access to the world's latest research
checkGet notified about relevant papers
checkSave papers to use in your research
checkJoin the discussion with peers
checkTrack your impact
Abstract
This paper describes a student project which is a major part of a senior level Operating Systems course at the Federal Institute of Technology in Lausanne. The project consists in conceiving and implementing an entire Operating System, where user jobs benefit from a simulated paged virtual memory on a DEC-LSI/11 based microprocessor. Students program in Portal, a modular high level language similar to Modula. The positive reactions we have obtained from our students center on satisfaction in having participated in defining specifications and having implemented an entire system themselves.
Related papers
Operating Systems Pilot: An Operating System for a Personal Computer
2008
The Pilot operating system provides a single-user, single-language environment for higher level software on a powerful personal computer. Its features include virtual memory, a large "fiat " file system, streams, network communication facilities, and concurrent programming support. Pilot thus provides rather more powerful facilities than are normally associated with personal computers. The exact facilities provided display interesting similarities to and differences from corresponding facilities provided in large multi-user systems. Pilot is implemented entirely in Mesa, a high-level system programming language. The modularization of the implementation displays some interesting aspects in terms of both the static structure and dynamic interactions of the various components. Key Words and Phrases: personal computer, operating system, high-level language, virtual memory,
An operating systems vade mecum
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
OPERATING SYSTEMS THREE EASY PIECES
iii iv humorous style. Whether you find them useful, or humorous, well, that's another matter entirely.
Observations on the development of an operating system
Proceedings of the eighth symposium on Operating systems principles - SOSP '81, 1981
The development of Pilot, an operating system for a personal computer, is reviewed, including a brief history and some of the problems and lessons encountered during this development. As part of understanding how Pilot and other operating systems come about, an hypothesis is presented that systems can be classified into five kinds according to the style and direction of their development, independent of their structure. A further hypothesis is presented that systems such as Pilot, and many others in widespread use, take about five to seven years to reach maturity, independent of the quality and quantity of the talent anplied to their development. The pressures, constraints, and problems of producing Pilot are discussed in the context of these hypotheses.
Pilot: an operating system for a personal computer
Communications of the ACM, 1980
The Pilot operating system provides a single-user, single-language environment for higher level software on a powerful personal computer. Its features include virtual memory, a large "fiat" file system, streams, network communication facilities, and concurrent programming support. Pilot thus provides rather more powerful facilities than are normally associated with personal computers. The exact facilities provided display interesting similarities to and differences from corresponding facilities provided in large multi-user systems. Pilot is implemented entirely in Mesa, a highlevel system programming language. The modularization of the implementation displays some interesting aspects in terms of both the static structure and dynamic interactions of the various components.
DEVELOPMENT OF AN OPERATING SYSTEM IN C
The aim of the thesis is to present a method of developing a stand-alone operating system and to explain the process of building the software and the dependencies and elements that the system consists of. In addition, the thesis briefly explains the reasons for utilizing C++ as the programming language of choice for the project and describes the process of booting the computer. Furthermore, computer organization and structure are briefly mentioned and labeled. Finally, the components of the system including the structure of the base of the system , and the more advanced topics are expressed and detailed.
ROAD MAP FOR PART ONE Chapter 1 Computer System Overview Chapter 2 Operating System Overview
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.
Experiences from turning Linux into an instructional operating system
Computer Applications in Engineering Education, 2020
The curriculum proposal for degrees related to Computer Science from the two main professional associations worldwide in information and communication technologies dedicate a considerable number of hours to operating system (OS) concepts, and so do the curricula defined by most universities. Nevertheless, the practical teaching of OS at an undergraduate level is currently a controversial issue. Some universities consider that the use of a real OS implies too steep a learning curve and its complexity can prevent an appropriate learning of the main concepts. Other universities consider that the use of an educational OS or the development of a simplified one from scratch are activities too far away from the reality that students will encounter in their professional lives. This paper presents a solution adopted at the University of Vigo, that tries to get the advantages of both approaches and avoid their drawbacks. It is based on combining small lab practices to acquire theoretical concepts and a medium-sized project to deal with the complexity of a real OS. We designed a new laboratory environment for teaching OS, which greatly facilitates the development of applications to test features both provided by Linux and developed by students, minimizing the effort required to create testing scenarios, and hiding, as far as necessary, less important OS details. We also show the results of the evaluation process carried out during the last academic years.
Operating Systems I: An Operating System Simulation Developed as Homework
This paper describes the series of homework assignments made during the fall 2000 Operating Systems I course at the University of North Dakota as well as the authors experience in making the assignments. The purpose of the assignments was not only to provide the student with a good understanding of how an operating system is developed and operates, but also to reinforce some basic skills that all graduating computer science majors ought to possess. Starting with a simple operating system simulation (one-queue round-robin CPU scheduler and one I/O queue) and progressing to a credit based priority CPU scheduler, multiple I/O queue, and page fault managing operating system simulation, the assignments mandated that the student develop a series of operating system simulations ranging in complexity.
Reflections on an operating system design
Communications of the ACM, 1976
The main features of a general purpose multiaccess operating system developed for the CDC 6400 at Berkeley are presented, and its good and bad points are discussed as they appear in retrospect. Distinctive features of the design were the use of capabilities for protection, and the organization of the system into a sequence of layers, each building on the facilities provided by earlier ones and protecting itself from the malfunctions of later ones. There were serious problems in maintaining the protection between layers when levels were added to the memory hierarchy; these problems are discussed and a new solution is described.
OS6—An Experimental Operating System for a Small Computer. Part 2: Input/Output and Filing System
1972
This paper is a description of a simple operating system, which runs in a virtual machine (implemented on a real machine by an interpreter). OS6 copes with only one user at a time, and is not a multi-programming system: many major problems associated with large operating systems have therefore been avoided or considerably simplified. It nevertheless has several features of interest, including the fact that it is written almost entirely in the high-level language BCPL. The most important single feature, however, is the hierarchical nature of its control structure, which avoids the need for a special job-control language.
Operating system directions for the next Millennium
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.
Extending the operating system to support an object-oriented environment
Sigplan Notices, 1989
Technology -ESPRIT and it stems from the identified need of providing simpler and more integrated environments for application development in large distributed systems.
Chapter 1: Operating System Models 2 Operating System Models 2.1 Introduction
Over the past several years, a number of trends affecting operating system design are witnessed and foremost among them is a move towards modularity. Operating systems such as Microsofts Windows, IBMs OS/2, C-DACs PARAS and others are splintered into discrete components, each having a small, well defined interface, and each communicating with others via inter-task message interface. The lowest level is the microkernel, which provides only essential OS services, such as context switching. Windows NT, for example, also includes a hardware abstraction layer (HAL) beneath its microkernel which enables the rest of the OS to perform irrespective of the processor underneath. This high level of OS portability is a primary driving force behind the modular, microkernel-based push.
Related topics
Loading Preview
Sorry, preview is currently unavailable. You can download the paper by clicking the button above.