DOCSLIB.ORG

The Architecture of a Reliable Operating System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Architecture of a Reliable Operating System The Architecture of a Reliable Operating System Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum Dept. of Computer Science, Vrije Universiteit Amsterdam, The Netherlands {jnherder, herbertb, beng, philip, ast}@cs.vu.nl Keywords: Operating System Reliability, Design and Implementation, Multiserver Architecture, MINIX 3 Abstract from crashes and other failures, results in a highly re- liable, completely multiserver operating system that In this paper, we discuss the architecture of a fully still looks and feels like UNIX. modular, self-healing operating system, which ex- While some of the mechanisms are well-known, ploits the principle of least authority to provide re- and multiserver operating systems have been first pro- liability beyond that of most other operating systems. posed years ago, to the best of our knowledge, we are The system can be characterized as a minimal kernel the first to explore such an extreme decomposition of with the entire operating system running as a set of the operating system that is designed for reliability, compartmentalized user-mode servers and drivers. while providing reasonable performance. Quite a few By moving most of the code to unprivileged user- ideas and technologies have been around for a long mode processes and restricting the powers of each time, but were often abandoned for performance rea- one, we gain proper fault isolation and limit the dam- sons. We believe that the time has come to reconsider age bugs can do. Moreover, the system has been de- the choices that were made in common operating sys- signed to survive and automatically recover from fail- tem design. ures in critical modules, such as device drivers, trans- parent to applications and without user intervention. 1.1 Contribution We used this design to develop a highly reli- The contribution of this work is the design and able, open-source, POSIX-conformant member of the implementation of an operating system that takes the UNIX family, which is freely available and has been concept of multiserver to an extreme in order to pro- downloaded 50,000 times in the past 3 months. vide a dependable computing platform. The concrete goal of this research is to build a UNIX-like operat- 1 INTRODUCTION ing system that can transparently survive crashes of critical components, such as device drivers. Operating systems are expected to function flaw- As we mentioned earlier, the answer that we came lessly, but, unfortunately, most of today’s operating up with is to break the system into manageable units systems frequently fail. As discussed in Sec. 2, many and rigidly control the power of each unit. The ulti- problems stem from the monolithic design that un- mate goal is that a fatal bug in, say, a device driver derlies most common systems. All operating system should not crash the operating system; instead, the functionality, for example, runs in kernel mode with- failed component should be automatically and trans- out proper fault isolation, so that any bug can poten- parently replaced by a fresh copy, and running user tially trash the entire system. processes should not be affected. Like other groups, we believe that reducing the To achieve this goal, our system provides: simple, operating system kernel is a first important step in yet efficient and reliable IPC; disentangling of inter- the direction of designing for reliability. In partic- rupt handling from user-mode device drivers; sepa- ular, running drivers and other core components in ration of policies and mechanisms; flexible, run-time user mode helps to minimize the damage that may be operating system configuration; decoupling of servers caused by bugs in such code. However, our system and drivers through a publish-subscribe system; and explores an extreme in the design space of UNIX-like error detection and transparent recovery for common operating systems where the entire operating system drivers failures. We will discuss these features in is run as a collection of independent, tightly restricted, more detail in the rest of the paper. user-mode processes. This structure, combined with While microkernels, user-mode device drivers, several explicit mechanisms for transparent recovery multiserver operating systems, fault tolerance, etc. are not new, no one has put all pieces together. We User User User User User User User User User believe that we are the first to realize a fully mod- ular, open-source, POSIX-conformant operating sys- tem that is designed to be highly reliable. The system VFS Inet UNIX server is called MINIX 3. It has been released (with all the Drivers Paging Microkernel source code) and 50,000 people have downloaded it Kernel space so far, as discussed later. Linux Mac OS X (a) (b) 1.2 Paper Outline Figure 1: Two typical monolithic systems discussed in Sec. 2.1: (a) Vanilla Linux and (b) Mac OS X. We first introduce how operating system structures have evolved over time (Sec. 2). Then we proceed with a discussion of the kernel and the organization of 2.2 Single-Server Systems the user-mode servers on top of it (Sec. 3). We review A single-server system has a reduced kernel, and some implementation issues (Sec. 4) and briefly dis- runs a large fraction of the operating system as a sin- cuss the system’s reliability (Sec. 5) and performance gle, monolithic user-mode server. In terms of reliabil- (Sec. 6). Finally, we draw conclusions (Sec. 7). ity, this setup adds little over monolithic systems, as there still is a single point of failure. The only gain in 2 RELATED WORK case of an operating system crash is a faster reboot. An advantage of this setup is that it preserves a This section illustrates the operating system design UNIX environment while one may experiment with a space with three typical structures and some variants microkernel approach. The combination of legacy ap- thereof. While most structures are probably familiar plications and real-time or secure modules allows for to the reader, we introduce them explicitly to show a smooth transition to a new computing environment. an overview of the design space that has monolithic Mach-UX [1] was one of the first systems to run systems at one extreme and ours at the other. BSD UNIX in user-mode on top of the Mach 3 mi- It is sometimes said that virtual machines and ex- crokernel, as shown in Fig. 2(a). Another example, okernels provide sufficient isolation and modularity shown in Fig. 2(b), is Perseus [9], running Linux and for making a system safe. However, these technolo- some specialized components for secure digital signa- gies provide an interface to an operating system, but tures on top of the L4 microkernel. do not represent a complete system by themselves. The operating system on top of a virtual machine or User User User User User User User User exokernel can have any of the following structures. User space BSD Unix L4 Linux GUI 2.1 Monolithic Systems Drivers Sign Monolithic kernels provide rich and powerful ab- Drivers Paging stractions. All operating system services are provided Kernel space Mach 3 L4 by a single, monolithic program that runs in kernel (a) (b) mode; applications run in user mode and can request services directly from the kernel. Figure 2: Two typical single-server systems discussed in Monolithic designs have some inherent problems Sec. 2.2: (a) Mach-UX and (b) Perseus. that affect their reliability. All operating system code, for example, runs at the highest privilege level with- 2.3 Multiserver Systems out proper fault isolation, so that any bug can poten- tially trash the entire system. With millions of lines In a multiserver design, the operating system en- of code (LoC) and 1-16 bugs per 1000 LOC [13, 14], vironment is formed by a set of cooperating servers. monolithic systems are likely to contain many bugs. Untrusted, third-party code such as device drivers Running untrusted, third-party code in the kernel also can be run in separate, user-mode modules to pre- diminishes the system’s reliability, as evidenced by vent faults from spreading. High reliability can be the fact that 70% to 85% of all operating system achieved by applying the principle of least author- crashes are caused by device drivers [2, 11] ity [10], and tightly controlling the powers of each. From a high-level reliability perspective, a mono- A multiserver design also has other advantages. lithic kernel is unstructured. The kernel may be parti- The modular structure, for example, makes system tioned into domains but there are no protection barri- administration easier and provides a convenient pro- ers enforced between the components. Two simplified gramming environment. A detailed discussion is out examples, Linux and MacOS X, are given in Fig. 1. of the scope of this paper. Several multiserver operating systems exist. An Before we continue with the discussion of the com- early system is MINIX [12], which distributed operat- ponents of MINIX 3, we give some examples to illus- ing system functionality over two user-mode servers, trate how our multiserver operating system actually but still ran the device drivers in the kernel, as shown works. Fig. 4 also shows some typical IPC interac- in Fig. 3(a). More recently, IBM Research designed tions initiated by user processes. Although the POSIX SawMill Linux [3], a multiserver environment on top operating system interface is implemented by multi- of the L4 microkernel, as illustrated in Fig. 3(b). ple servers, system calls are transparently targeted to While the goal was a full multiserver variant of Linux, the right server by the system libraries. Four exam- the project never passed the stage of a rudimentary ples are given below: prototype, and was then abandoned when the people (1) The application that wants to create a child pro- working on it left IBM.
Load more

Recommended publications
  • A Programmable Microkernel for Real-Time Systems∗
    A Programmable Microkernel for Real-Time Systems∗ Christoph M. Kirsch Marco A.A. Sanvido Thomas A. Henzinger University of Salzburg VMWare Inc. EPFL and UC Berkeley [email protected] tah@epfl.ch ABSTRACT Categories and Subject Descriptors We present a new software system architecture for the im- D.4.7 [Operating Systems]: Organization and Design— plementation of hard real-time applications. The core of the Real-time systems and embedded systems system is a microkernel whose reactivity (interrupt handling as in synchronous reactive programs) and proactivity (task General Terms scheduling as in traditional RTOSs) are fully programma- Languages ble. The microkernel, which we implemented on a Strong- ARM processor, consists of two interacting domain-specific Keywords virtual machines, a reactive E (Embedded) machine and a proactive S (Scheduling) machine. The microkernel code (or Real Time, Operating System, Virtual Machine microcode) that runs on the microkernel is partitioned into E and S code. E code manages the interaction of the system 1. INTRODUCTION with the physical environment: the execution of E code is In [9], we advocated the E (Embedded) machine as a triggered by environment interrupts, which signal external portable target for compiling hard real-time code, and in- events such as the arrival of a message or sensor value, and it troduced, in [11], the S (Scheduling) machine as a universal releases application tasks to the S machine. S code manages target for generating schedules according to arbitrary and the interaction of the system with the processor: the exe- possibly non-trivial strategies such as nonpreemptive and cution of S code is triggered by hardware interrupts, which multiprocessor scheduling.
    [Show full text]
  • The Design of the EMPS Multiprocessor Executive for Distributed Computing
    The design of the EMPS multiprocessor executive for distributed computing Citation for published version (APA): van Dijk, G. J. W. (1993). The design of the EMPS multiprocessor executive for distributed computing. Technische Universiteit Eindhoven. https://doi.org/10.6100/IR393185 DOI: 10.6100/IR393185 Document status and date: Published: 01/01/1993 Document Version: Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication: • A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.
    [Show full text]
  • Blackberry QNX Multimedia Suite
    PRODUCT BRIEF QNX Multimedia Suite The QNX Multimedia Suite is a comprehensive collection of media technology that has evolved over the years to keep pace with the latest media requirements of current-day embedded systems. Proven in tens of millions of automotive infotainment head units, the suite enables media-rich, high-quality playback, encoding and streaming of audio and video content. The multimedia suite comprises a modular, highly-scalable architecture that enables building high value, customized solutions that range from simple media players to networked systems in the car. The suite is optimized to leverage system-on-chip (SoC) video acceleration, in addition to supporting OpenMAX AL, an industry open standard API for application-level access to a device’s audio, video and imaging capabilities. Overview Consumer’s demand for multimedia has fueled an anywhere- o QNX SDK for Smartphone Connectivity (with support for Apple anytime paradigm, making multimedia ubiquitous in embedded CarPlay and Android Auto) systems. More and more embedded applications have require- o Qt distributions for QNX SDP 7 ments for audio, video and communication processing capabilities. For example, an infotainment system’s media player enables o QNX CAR Platform for Infotainment playback of content, stored either on-board or accessed from an • Support for a variety of external media stores external drive, mobile device or streamed over IP via a browser. Increasingly, these systems also have streaming requirements for Features at a Glance distributing content across a network, for instance from a head Multimedia Playback unit to the digital instrument cluster or rear seat entertainment units. Multimedia is also becoming pervasive in other markets, • Software-based audio CODECs such as medical, industrial, and whitegoods where user interfaces • Hardware accelerated video CODECs are increasingly providing users with a rich media experience.
    [Show full text]
  • Blackberry Playbook OS 2.0 Performs. Best in Class Communications
    BlackBerry PlayBook OS 2.0 Performs. Best in class communications. Powerful productivity. Performance powerhouse. What’s new and exciting about PlayBook™ OS 2.0 A proven performance powerhouse PlayBook OS 2.0 builds on proven performance through powerful hardware and intuitive, easy to use gestures. BlackBerry® PlayBook™ packs a blazing fast dual core processor, two HD 1080p video cameras, and 1 GB of RAM for a high performance experience that is up to the task – whatever it may be. The best of BlackBerry® comes built-in The BlackBerry PlayBook now gives you the BlackBerry communications experience you love, built for a tablet. PlayBook OS 2.0 introduces built-in email that lets you create, edit and format messages, and built-in contacts app and social calendar that connect to your social networks to give you a complete profile ™ of your contacts, including recent status updates. So, seize the BlackBerry App World moment and share it with the power of BlackBerry. The BlackBerry PlayBook has all your favorite apps and thousands more. Games like Angry Birds and Cut The Rope, BlackBerry® Bridge™ Technology social networking sites like Facebook, and even your favorite books from Kobo - the apps you want are here for you to New BlackBerry® Bridge™ features let your BlackBerry® smartphone discover in the BlackBerry AppWorld™ storefront. act as a keyboard and mouse for your BlackBerry PlayBook, giving you wireless remote control of your tablet. Perfect for pausing a movie when your BlackBerry PlayBook is connected to your TV with An outstanding web experience an HDMI connection. Plus, if you’re editing a document or browsing BlackBerry PlayBook puts the power of the real Internet at your a webpage on your BlackBerry smartphone and want to see it on a fingertips with a blazing fast Webkit engine supporting HTML5 larger display, BlackBerry Bridge lets you switch screens to view on and Adobe® Flash® 11.1.
    [Show full text]
  • QNX Neutrino® Realtime Operating System
    PRODUCT BRIEF QNX Neutrino® Realtime Operating System QNX Neutrino® is a full-featured and robust operating system designed to enable the next-generation of products for automotive, medical and industrial embedded systems. Microkernel design and modular architecture enable customers to create highly optimized and reliable systems with low total cost of ownership. With QNX Neutrino®, embedded systems designers can create compelling, safe and secure devices built on a highly reliable operating system software foundation that helps guard against system malfunctions, malware and cyber security breaches. For over 35 years, thousands of companies have deployed and The QNX Neutrino microkernel memory-protected architecture trusted QNX realtime technology to ensure the best combination provides a foundation to build safety-critical systems. QNX of performance, security and reliability in the world’s most Neutrino® is 100% API compatible with QNX pre-certified mission-critical systems. software products that address compliance with safety certifica- tions in automotive (ISO 26262), industrial safety (IEC 61508) and Built-in mission critical reliability medical devices (IEC 62304). Time-tested and field-proven, the QNX Neutrino® is built on a true microkernel architecture. Under this system, every driver, Maximize software investments application, protocol stack, and filesystem runs outside the kernel QNX Neutrino® provides a common software platform that can be in the safety of memory-protected user space. Virtually any deployed for safety certified and non-certified projects across a component can fail and be automatically restarted without broad range of hardware platforms. Organizations can reduce aecting other components or the kernel. No other commercial duplication, costs and risks associated with the deployment of RTOS provides such a high level of fault containment and recovery.
    [Show full text]
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra
    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
    [Show full text]
  • Building Performance Measurement Tools for the MINIX 3 Operating System
    Building Performance Measurement Tools for the MINIX 3 Operating System Rogier Meurs August 2006 Contents 1 INTRODUCTION 1 1.1 Measuring Performance 1 1.2 MINIX 3 2 2 STATISTICAL PROFILING 3 2.1 Introduction 3 2.2 In Search of a Timer 3 2.2.1 i8259 Timers 3 2.2.2 CMOS Real-Time Clock 3 2.3 High-level Description 4 2.4 Work Done in User-Space 5 2.4.1 The SPROFILE System Call 5 2.5 Work Done in Kernel-Space 5 2.5.1 The SPROF Kernel Call 5 2.5.2 Profiling using the CMOS Timer Interrupt 6 2.6 Work Done at the Application Level 7 2.6.1 Control Tool: profile 7 2.6.2 Analyzing Tool: sprofalyze.pl 7 2.7 What Can and What Cannot be Profiled 8 2.8 Profiling Results 8 2.8.1 High Scoring IPC Functions 8 2.8.2 Interrupt Delay 9 2.8.3 Profiling Runs on Simulator and Other CPU Models 12 2.9 Side-effect of Using the CMOS Clock 12 3 CALL PROFILING 13 3.1 Introduction 13 3.1.1 Compiler-supported Call Profiling 13 3.1.2 Call Paths, Call and Cycle Attribution 13 3.2 High-level Description 14 3.3 Work Done in User-Space 15 3.3.1 The CPROFILE System Call 15 3.4 Work Done in Kernel-Space 16 3.4.1 The PROFBUF and CPROF Kernel Calls 16 3.5 Work Done in Libraries 17 3.5.1 Profiling Using Library Functions 17 3.5.2 The Procentry Library Function 17 3.5.3 The Procexit Library Function 20 3.5.4 The Call Path String 22 3.5.5 Testing Overhead Elimination 23 3.6 Profiling Kernel-Space/User-Space Processes 24 3.6.1 Differences in Announcing and Table Sizes 24 3.6.2 Kernel-Space Issue: Reentrancy 26 3.6.3 Kernel-Space Issue: The Call Path 26 3.7 Work Done at the Application
    [Show full text]
  • Amigaos 3.2 FAQ 47.1 (09.04.2021) English
    $VER: AmigaOS 3.2 FAQ 47.1 (09.04.2021) English Please note: This file contains a list of frequently asked questions along with answers, sorted by topics. Before trying to contact support, please read through this FAQ to determine whether or not it answers your question(s). Whilst this FAQ is focused on AmigaOS 3.2, it contains information regarding previous AmigaOS versions. Index of topics covered in this FAQ: 1. Installation 1.1 * What are the minimum hardware requirements for AmigaOS 3.2? 1.2 * Why won't AmigaOS 3.2 boot with 512 KB of RAM? 1.3 * Ok, I get it; 512 KB is not enough anymore, but can I get my way with less than 2 MB of RAM? 1.4 * How can I verify whether I correctly installed AmigaOS 3.2? 1.5 * Do you have any tips that can help me with 3.2 using my current hardware and software combination? 1.6 * The Help subsystem fails, it seems it is not available anymore. What happened? 1.7 * What are GlowIcons? Should I choose to install them? 1.8 * How can I verify the integrity of my AmigaOS 3.2 CD-ROM? 1.9 * My Greek/Russian/Polish/Turkish fonts are not being properly displayed. How can I fix this? 1.10 * When I boot from my AmigaOS 3.2 CD-ROM, I am being welcomed to the "AmigaOS Preinstallation Environment". What does this mean? 1.11 * What is the optimal ADF images/floppy disk ordering for a full AmigaOS 3.2 installation? 1.12 * LoadModule fails for some unknown reason when trying to update my ROM modules.
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • Morpho-Syntactic Interactions Between V and C in Romance1
    Dialectologia. Special issue, V (2015), 293-319. ISSN: 2013-2247 Received 7 August 2015. Accepted 26 September 2015. MORPHO-SYNTACTIC INTERACTIONS BETWEEN V AND C IN ROMANCE1 Ángel J. GALLEGO Universitat Autònoma de Barcelona [email protected] Abstract This paper discusses a series of morpho-syntactic (a)symmetries that emerge in the vP and CP levels of different Romance languages. The (a)symmetries considered indicate a P or D oriented nature for specific functional heads placed in the vP and CP domains, an idea that has been at the forefront of micro-parametric studies ever since the 80s (cf. Kayne 1984, 2000; Uriagereka 1995). The consequences of this investigation for the status of parameter theory are further considered (cf. Chomsky 1981; Baker 2001; Biberauer 2008; Kayne 2000; Picallo 2014) and the study of the lexicon, arguably the main locus of linguistic variation (cf. Halle & Marantz 1993; Hale & Keyser 1993; Starke 2014; Uriagereka 2008). Keywords complementizers, lexicon, micro-parameters, Romance languages, variation, verbs INTERACCIONES MORFOSINTÁCTICAS ENTRE V Y C EN ROMANCE Resumen Este trabajo discute una serie de (a)simetrías morfosintácticas que aparecen en los niveles del Sv y el SC de diferentes lenguas románicas. Dichas (a)simetrías indican que núcleos funcionales pertenecientes a los dominios Sv y SC despliegan una naturaleza similar a P o a D, una idea que ha 1 A previous version of this paper was presented at the V Westmost Europe Dialect Syntax (Wedisyn) Meeting, held at the Universidad Autónoma de Madrid (24-25 April 2014), whose audience I thank for questions and suggestions. Special thanks go to Roberta D’Alessandro, Carlota de Benito, Inés Fernández-Ordóñez, and Álvaro Octavio de Toledo for comments and (on-going) discussion.
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO
    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO..........................................................................................................................................1 Martin Hinner < [email protected]>, http://martin.hinner.info............................................................1 1. Introduction..........................................................................................................................................1 2. Volumes...............................................................................................................................................1 3. DOS FAT 12/16/32, VFAT.................................................................................................................2 4. High Performance FileSystem (HPFS)................................................................................................2 5. New Technology FileSystem (NTFS).................................................................................................2 6. Extended filesystems (Ext, Ext2, Ext3)...............................................................................................2 7. Macintosh Hierarchical Filesystem − HFS..........................................................................................3 8. ISO 9660 − CD−ROM filesystem.......................................................................................................3 9. Other filesystems.................................................................................................................................3
    [Show full text]