DOCSLIB.ORG

Communication in Microkernel-Based Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Communication in Microkernel-Based Operating Systems Dissertation zur Erlangung des akademischen Grades Doktoringenieur (Dr.-Ing.) vorgelegt an der Technischen Universit¨atDresden Fakult¨atInformatik eingereicht von Diplom-Informatiker Ronald Aigner geboren am 20. Mai 1976 in Dresden Gutachter: Prof. Dr. rer. nat. Hermann H¨artig Technische Universit¨atDresden Prof. Dr. Klaus Meyer-Wegener Friedrich Alexander Universit¨atErlangen-N¨urnberg Tag der Verteidigung: 21. Januar 2011 Dresden im Mai 2011 Communication in Microkernel-Based Operating Systems Ronald Aigner Technische Universit¨atDresden July 2010 ii Abstract Communication in microkernel-based systems is much more frequent than system calls known from monolithic kernels. This can be attributed to the placement of system services into their own protection domains. Communication has to be fast to avoid unnecessary overhead. Also, communication channels in microkernel-based systems are used for more than just remote procedure calls. In distributed systems, which also have a componentized design, it is state of the art to use tools to generate stubs for the communication between components. The communication interfaces of components are described in an interface definition language (IDL). In contrast to distributed systems, components of a microkernel-based system run on the same architecture and message delivery is guaranteed. In this Thesis, I explore the different kinds of communication, which can be used in microkernel-based systems, as well as their possible representation in IDL. Specifically, I introduce the syntax to describe kernel objects in IDL. I discuss the complexity of IDL compilers and its relation to the complexity of the IDL. Furthermore, I evaluate the performance of the communication stubs generated by different IDL compilers and discuss techniques to minimize performance overhead in generated stubs. I validated these techniques by implementing the Drops IDL Compiler { Dice. Finally, this Thesis presents a mechanism to measure the frequency and performance of invocations of gen- erated communication code. I used this technique to conduct measurements in highly complex systems and introducing the least possible overhead. iii Acknowledgments First, I would like to thank my supervisor, Prof. Hermann H¨artig. He provided the environment to pursue my research ideas and to learn so much about operating systems and microkernels in particular. I want to express my gratitude for not giving up on me and supporting this work. He created a nourishing environment by shepherding so many intelligent people in his group. Furthermore, I would like to thank my reviewer, Prof. Meyer-Wegener. His infinite patience and positive feedback allowed me to look at this work from different angles and find new ideas behind the corners. Of course this Thesis would not have been possible without all the wonderful people of the Operating Systems chair at TU Dresden. Discussions with them always questioned my assumptions and made me constantly aware of flaws in my work. I would especially like to thank Lars Reuther, Martin Pohlack and Adam Lackorszynski. Last but certainly not least, I wish to thank my family. My wife and kids gave me the balance to stay on track, even if the work seemed overwhelming. And my parents: You made me who I am. iv Contents 1 Introduction1 2 Related Work5 2.1 Message Passing Interface...........................5 2.2 Remote Procedure Calls............................5 2.3 Sun RPC....................................6 2.4 Firefly......................................6 2.5 Spring......................................7 2.6 Pebble......................................7 2.7 MIG - The Mach Interface Generator.....................8 2.7.1 Specification Language.........................9 2.7.2 Usage Problems and Hints.......................9 2.7.3 Optimizations.............................. 10 2.8 Flick - Flexible Interface Compiler Kit.................... 11 2.9 Concert..................................... 14 2.10 Spec#...................................... 14 2.11 Barrelfish.................................... 15 2.12 CORBA..................................... 15 2.13 Peregrine.................................... 16 2.14 IDL Compilers for L4 µ-Kernels........................ 17 2.14.1 IDL4 ................................... 17 2.14.2 Magpie................................. 17 2.15 DCE++..................................... 18 2.16 Heidi....................................... 18 2.17 Ada....................................... 19 2.18 Summary.................................... 19 3 Forms of Communication 21 3.1 Message Passing................................ 21 3.2 Asynchronous Servers............................. 23 3.3 Shared Memory................................. 25 3.4 Streaming.................................... 27 3.5 Security..................................... 27 v vi CONTENTS 3.5.1 Access Control............................. 28 3.5.2 Shared Memory Communication................... 29 3.5.3 Robustness............................... 30 3.5.4 Denial of Service............................ 30 3.6 Summary.................................... 31 4 Portability 33 4.1 Platform Independence............................. 34 4.1.1 Platform Dependent Types and Platform Independent Attributes. 35 4.2 Optimization.................................. 36 4.2.1 Parameter reordering......................... 37 4.2.2 Copy Avoidance............................ 38 4.2.3 Memory Allocation........................... 39 4.2.4 Target Language Compiler...................... 39 4.3 Usability..................................... 40 4.4 Summary.................................... 42 5 Integration 43 5.1 IDL Extensions................................. 43 5.1.1 Indirect Parts.............................. 43 5.1.2 Aliasing Types............................. 44 5.1.3 User-Defined Types.......................... 44 5.1.4 Concurrent Data Access........................ 45 5.1.5 Operation Identifiers.......................... 45 5.1.6 Array Size................................ 46 5.2 Target Code Generation............................ 47 5.2.1 Factory Concept............................ 48 5.2.2 Message Buffer Layout......................... 49 5.2.3 Tracing................................. 51 5.2.4 Test Suite Generation......................... 51 5.3 Infrastructure Integration........................... 52 5.3.1 Automatic Service Lookup...................... 52 5.3.2 Resource Accounting.......................... 52 5.3.3 Resource Reservation......................... 53 5.4 Real-Time Communication.......................... 53 5.5 Summary.................................... 54 6 Evaluation 55 6.1 Analyze Method Invocations......................... 55 6.1.1 Scenario 1: L4Linux with L4 console................. 56 6.1.2 Scenario 2: L4Linux with L4 console and ORe network....... 61 6.1.3 Scenario 3: Netfilter.......................... 62 6.1.4 Scenario 4: L4Linux with DOpE................... 65 6.1.5 Scenario 5: Verner { video player................... 66 CONTENTS vii 6.1.6 Scenario 6: JTop { a DOpE application............... 68 6.1.7 Scenario 7: BLAC........................... 69 6.1.8 Summary................................ 70 6.2 Performance Benchmark............................ 75 6.2.1 Comparing Stub Code Generators for Fiasco............ 75 6.2.2 Comparing Stub Code Generators for Hazelnut........... 75 6.2.3 Comparing Hardware Architectures................. 77 6.2.4 Comparing Compiler Versions..................... 77 6.2.5 Comparing Stub Code Generators for Pistachio........... 79 6.2.6 Comparing Stub Code Generators for Linux sockets........ 82 6.3 Micro-benchmarks............................... 84 6.3.1 Short IPC................................ 84 6.3.2 Indirect string IPC versus direct IPC................. 85 6.3.3 Indirect string IPC versus Shared Memory.............. 88 6.4 Code Complexity................................ 89 6.4.1 Test Suite................................ 89 6.4.2 Tracing................................. 90 6.4.3 Assembly code generation....................... 90 6.4.4 Indirect String Communication.................... 91 6.4.5 Resource Reservation......................... 92 6.4.6 Default Timeout............................ 92 6.4.7 Generated Code............................ 93 6.4.8 IDL Compiler.............................. 94 6.4.9 dynrpc Code Complexity....................... 97 6.5 Summary.................................... 98 7 Conclusion and Outlook 99 7.1 Contributions.................................. 99 7.2 Outlook..................................... 100 A Performance Measurement Results 103 A.1 Performance of Stub-Code Generator for Fiasco............... 103 A.1.1 GCC version 3.4............................ 103 A.1.2 GCC version 2.95............................ 105 A.2 Performance of Stub-Code Generator for Hazelnut............. 107 A.3 Comparing Hardware Architecture...................... 109 A.4 Comparing Compiler Versions......................... 113 A.5 Comparing Stub-Code Generators for Pistachio............... 115 A.6 Comparing Stub-Code Generators for Linux sockets............ 117 viii CONTENTS List of Tables 6.1 Number of invocations for L4Linux with L4 console counted with instru- mented stubs.................................. 57 6.2 Size of IDL method calls for L4Linux with L4 console counted with in- strumented stubs................................ 58 6.3 Number of IPCs sorted by size for L4Linux with L4 console counted by kernel extension................................
Recommended publications
  • A Programmable Microkernel for Real-Time Systems∗

    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.
  • The Design of the EMPS Multiprocessor Executive for Distributed Computing

    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.
  • Uva-DARE (Digital Academic Repository)

    Uva-DARE (Digital Academic Repository)

    UvA-DARE (Digital Academic Repository) On the construction of operating systems for the Microgrid many-core architecture van Tol, M.W. Publication date 2013 Link to publication Citation for published version (APA): van Tol, M. W. (2013). On the construction of operating systems for the Microgrid many-core architecture. General rights It is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons). Disclaimer/Complaints regulations If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask the Library: https://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. You will be contacted as soon as possible. UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl) Download date:27 Sep 2021 General Bibliography [1] J. Aas. Understanding the linux 2.6.8.1 cpu scheduler. Technical report, Silicon Graphics Inc. (SGI), Eagan, MN, USA, February 2005. [2] D. Abts, S. Scott, and D. J. Lilja. So many states, so little time: Verifying memory coherence in the Cray X1. In Proceedings of the 17th International Symposium on Parallel and Distributed Processing, IPDPS '03, page 10 pp., Washington, DC, USA, April 2003.
  • High Performance Computing Systems

    High Performance Computing Systems

    High Performance Computing Systems Multikernels Doug Shook Multikernels Two predominant approaches to OS: – Full weight kernel – Lightweight kernel Why not both? – How does implementation affect usage and performance? Gerolfi, et. al. “A Multi-Kernel Survey for High- Performance Computing,” 2016 2 FusedOS Assumes heterogeneous architecture – Linux on full cores – LWK requests resources from linux to run programs Uses CNK as its LWK 3 IHK/McKernel Uses an Interface for Heterogeneous Kernels – Resource allocation – Communication McKernel is the LWK – Only operable with IHK Uses proxy processes 4 mOS Embeds LWK into the Linux kernel – LWK is visible to Linux just like any other process Resource allocation is performed by sysadmin/user 5 FFMK Uses the L4 microkernel – What is a microkernel? Also uses a para-virtualized Linux instance – What is paravirtualization? 6 Hobbes Pisces Node Manager Kitten LWK Palacios Virtual Machine Monitor 7 Sysadmin Criteria Is the LWK standalone? Which kernel is booted by the BIOS? How and when are nodes partitioned? 8 Application Criteria What is the level of POSIX support in the LWK? What is the pseudo file system support? How does an application access Linux functionality? What is the system call overhead? Can LWK and Linux share memory? Can a single process span Linux and the LWK? Does the LWK support NUMA? 9 Linux Criteria Are LWK processes visible to standard tools like ps and top? Are modifications to the Linux kernel necessary? Do Linux kernel changes propagate to the LWK?
  • Amigaos 3.2 FAQ 47.1 (09.04.2021) English

    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.
  • Chapter 1. Origins of Mac OS X

    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.
  • Using Microsoft Visual Studio to Create a Graphical User Interface ECE 480: Design Team 11

    Using Microsoft Visual Studio to Create a Graphical User Interface ECE 480: Design Team 11

    Using Microsoft Visual Studio to Create a Graphical User Interface ECE 480: Design Team 11 Application Note Joshua Folks April 3, 2015 Abstract: Software Application programming involves the concept of human-computer interaction and in this area of the program, a graphical user interface is very important. Visual widgets such as checkboxes and buttons are used to manipulate information to simulate interactions with the program. A well-designed GUI gives a flexible structure where the interface is independent from, but directly connected to the application functionality. This quality is directly proportional to the user friendliness of the application. This note will briefly explain how to properly create a Graphical User Interface (GUI) while ensuring that the user friendliness and the functionality of the application are maintained at a high standard. 1 | P a g e Table of Contents Abstract…………..…………………………………………………………………………………………………………………………1 Introduction….……………………………………………………………………………………………………………………………3 Operation….………………………………………………….……………………………………………………………………………3 Operation….………………………………………………….……………………………………………………………………………3 Visual Studio Methods.…..…………………………….……………………………………………………………………………4 Interface Types………….…..…………………………….……………………………………………………………………………6 Understanding Variables..…………………………….……………………………………………………………………………7 Final Forms…………………....…………………………….……………………………………………………………………………7 Conclusion.…………………....…………………………….……………………………………………………………………………8 2 | P a g e Key Words: Interface, GUI, IDE Introduction: Establishing a connection between
  • Dualbooting Amigaos 4 and Amigaos 3.5/3.9

    Dualbooting Amigaos 4 and Amigaos 3.5/3.9

    Dualbooting AmigaOS 4 and AmigaOS 3.5/3.9 By Christoph Gutjahr. Licensed under the GNU Free Documentation License This tutorial explains how to turn a classic Amiga into a dualboot system that lets you choose the desired operating system - AmigaOS 4 or AmigaOS 3.5/3.9 - at every cold start. A "cold start" happens when... 1. the computer has just been switched on 2. you press the key combination Control-Amiga-Amiga for more than ten seconds while running AmigaOS 3 3. you press Control-Alt-Alt (instead of Control-Amiga-Amiga) under AmigaOS 4 During a "warm reboot" (e.g. by shortly pressing Control-Amiga-Amiga), the operating system that is currently used will be booted again. Requirements This tutorial is only useful for people using AmigaOS 3.5 or 3.9 in addition to AmigaOS 4. If you're using an older version of OS 3, you can not use the scripts described below. The Amiga in question should have two boot partitions - one for AmigaOS 4 and one for AmigaOS 3.5/3.9, both should be below the famous 4 GB barrier. The OS 4 partition must have a higher boot priority. Two different solutions There are two different approaches for dualbooting: the first one described below will display a simple 'boot menu' at every cold boot, asking the user to select the OS he wants to boot. The other solution explained afterwards will always boot into AmigaOS 4, unless the user enters the "Early Startup Menu" and selects the OS 3 partition as the boot drive.
  • Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming

    Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming

    Improving Learning of Programming Through E-Learning by Using Asynchronous Virtual Pair Programming Abdullah Mohd ZIN Department of Industrial Computing Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Sufian IDRIS Department of Computer Science Faculty of Information Science and Technology National University of Malaysia Bangi, MALAYSIA Nantha Kumar SUBRAMANIAM Open University Malaysia (OUM) Faculty of Information Technology and Multimedia Communication Kuala Lumpur, MALAYSIA ABSTRACT The problem of learning programming subjects, especially through distance learning and E-Learning, has been widely reported in literatures. Many attempts have been made to solve these problems. This has led to many new approaches in the techniques of learning of programming. One of the approaches that have been proposed is the use of virtual pair programming (VPP). Most of the studies about VPP in distance learning or e-learning environment focus on the use of the synchronous mode of collaboration between learners. Not much research have been done about asynchronous VPP. This paper describes how we have implemented VPP and a research that has been carried out to study the effectiveness of asynchronous VPP for learning of programming. In particular, this research study the effectiveness of asynchronous VPP in the learning of object-oriented programming among students at Open University Malaysia (OUM). The result of the research has shown that most of the learners have given positive feedback, indicating that they are happy with the use of asynchronous VPP. At the same time, learners did recommend some extra features that could be added in making asynchronous VPP more enjoyable. Keywords: Pair-programming; Virtual Pair-programming; Object Oriented Programming INTRODUCTION Delivering program of Information Technology through distance learning or E- Learning is indeed a very challenging task.
  • The Joe-E Language Specification (Draft)

    The Joe-E Language Specification (Draft)

    The Joe-E Language Specification (draft) Adrian Mettler David Wagner famettler,[email protected] February 3, 2008 Disclaimer: This is a draft version of the Joe-E specification, and is subject to change. Sections 5 - 7 mention some (but not all) of the aspects of the Joe-E language that are future work or current works in progress. 1 Introduction We describe the Joe-E language, a capability-based subset of Java intended to make it easier to build secure systems. The goal of object capability languages is to support the Principle of Least Authority (POLA), so that each object naturally receives the least privilege (i.e., least authority) needed to do its job. Thus, we hope that Joe-E will support secure programming while remaining familiar to Java programmers everywhere. 2 Goals We have several goals for the Joe-E language: • Be familiar to Java programmers. To minimize the barriers to adoption of Joe-E, the syntax and semantics of Joe-E should be familiar to Java programmers. We also want Joe-E programmers to be able to use all of their existing tools for editing, compiling, executing, debugging, profiling, and reasoning about Java code. We accomplish this by defining Joe-E as a subset of Java. In general: Subsetting Principle: Any valid Joe-E program should also be a valid Java program, with identical semantics. This preserves the semantics Java programmers will expect, which are critical to keeping the adoption costs manageable. Also, it means all of today's Java tools (IDEs, debuggers, profilers, static analyzers, theorem provers, etc.) will apply to Joe-E code.
  • Access Control and Operating System

    Access Control and Operating System

    Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store
  • Extensible Distributed Operating System for Reliable Control Systems

    Extensible Distributed Operating System for Reliable Control Systems

    194 Extensible Distributed Operating System for Reliable Control Systems Katsumi Maruyama, Kazuya Kodama, Soichiro Hidaka, Hiromichi Hashizume National Institute of Informatics, 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo, Japan Email:{maruyama,kazuya,hidaka,has}@nii.ac.jp Abstract small monitor-like OSs are used. However, these monitor- like OSs lack program protection mechanisms, and program Since most control systems software is hardware-related, development is difficult. real-time-oriented and complex, adaptable OSs which help Therefore, an extensible/adaptable OS for control sys- program productivity and maintainability improvement are tems is required . We are developing a new OS character- in strong demand. ized by: We are developing an adaptable and extensible OS based on micro-kernel and multi-server scheme: each server runs • Use of an efficient and flexible micro-kernel (L4-ka). • Multi-server based modular OS. (Each OS service is in a protected mode interacting only via messages, and implemented as individual user-level process.) could be added/extended/deleted easily. Since this OS is • Robustness. Only the micro-kernel runs in kernel highly modularized, inter-process messaging overhead is a mode and in kernel space. Other modules run in a pro- concern. Our implementation proved good efficiency and tected user space and mode. maintainability. • Hardware driver programs in user-level process. • Flexible distributed processing by global message passing. 1. Introduction This OS structure proved to enhance OS modularity and ease of programming. However, inter-process messaging Most systems, from large scale public telephone switch- overhead should be considered . We measured the overhead, ing systems to home electronics, are controlled by software, and the overhead was proved to be small enough.