A New Look at Microkernel-Based UNIX Operating Systems : Lessons in Performance and Compatibility

An important trend in operating system development is the restructuring of the traditional monolithic operating system kernel into independent servers running on top of a minimal nucleus or “microkernel”. This approach arises out of the need for modularity and flexibility in managing the ever-growing complexity caused by the introduction of new functions and new architectures. In particular, it provides a solid architectural basis for distribution, fault tolerance, and security. Microkernel-based operating systems have been a focus of research for a number of years, and are now beginning to play a role in commercial UNIX systems. The ultimate feasibility of this attractive approach is not yet widely recognised, however. A primary concern is efficiency: can a microkernel-based modular operating system provide performance comparable to that of a monolithic kernel when running on comparable architectures? The elegance and flexibility of the client-server model may exact a cost in message-handling and context-switching overhead. If this penalty is too great, commercial acceptance will be limited. Another pragmatic concern is compatibility: in an industry relying increasingly on portability and standardisation, compatible interfaces are needed not only at the level of application programs, but also for device drivers, streams modules, and other components. In many cases, binary as well as source compatibility is required. These concerns affect the structure and organisation of the operating system. The Chorus team has spent the past six years studying and experimenting with UNIX “kernelisation” as an aspect of its work in modular distributed and real-time systems. In this paper we examine aspects of the current CHORUS system in terms of its evolution from the previous version. Our focus is on pragmatic issues such as performance and compatibility, as well as considerations of modularity and software engineering. hhhhhhhhhhhhhhhh Appeared in the Proceedings of the EurOpen Spring’91 Conference, Tromsoe, Norway, May 20-24, 1991.  UNIX is a registered trademark of UNIX System Laboratories, Inc. in the U.S.A. and other countries.  CHORUS is a registered trademark of Chorus systèmes.  Chorus systèmes, 1991 − 1 − February, 1991 Chorus systèmes A New Look at Microkernel-Based UNIX Operating Systems CS/TR-91-7 1. Microkernel Architectures A recent trend in operating system development consists of structuring the operating system as a modular set of system servers which sit on top of a minimal microkernel, rather than using the traditional monolithic structure. This new approach promises to help meet system and platform builders’ needs for a sophisticated operating system development environment that can cope with growing complexity, new architectures, and changing market conditions. In this operating system architecture, the microkernel provides system servers with generic services, such as processor scheduling and memory management, independent of a specific operating system. The microkernel also provides a simple inter-process communication (IPC) facility that allows system servers to call each other and exchange data regardless of where they are executed, in a multiprocessor, multicomputer, or network configuration. This combination of primitive services forms a standard base which in turn supports the implementation of functions that are specific to a particular operating system or environment. These system-specific functions can then be configured, as appropriate, into system servers managing the other physical and logical resources of a computer system, such as files, devices and highlevel communication services. We refer to such a set of system servers as a subsystem. Realtime systems tend to be built along similar lines, with a simple, generic executive supporting application-specific real-time tasks. 1.1 UNIX and Microkernels UNIX introduced the concept of a standard, hardware-independent operating system, whose portability allowed platform builders to reduce their time to market by obviating the need to develop proprietary operating systems for each new platform. However, as more function and flexibility is continually demanded, it is unavoidable that today’s versions become increasingly more complex. For example, UNIX is being extended with facilities for real-time applications and on-line transaction processing. Even more fundamental is the move toward distributed systems. It is desirable in today’s computing environments that new hardware and software resources, such as specialised servers and applications, be integrated into a single system, distributed over a network. The range of communication media commonly encountered includes shared memory, buses, high-speed networks, local-area networks, and wide-area networks. This trend to integrate new hardware and software components will become fundamental as collective computing environments emerge. To support the addition of function to UNIX and its migration to distributed environments, it is desirable to map UNIX onto a microkernel architecture, where machine dependencies may be isolated from unrelated abstractions and facilities for distribution may be incorporated at a very low level. The attempt to reorganise UNIX to work within a microkernel framework poses problems, however, if the resultant system is to behave exactly as a traditional UNIX implementation. A primary concern is efficiency: a microkernel-based modular operating system must provide performance comparable to that of a monolithic kernel. The elegance and flexibility of the clientserver model may exact a cost in message-handling and context-switching overhead. If this penalty is too great, commercial acceptance will be limited. Another pragmatic concern is compatibility: in an industry relying increasingly upon portability and standardisation, compatible interfaces are needed not only at the level of application programs, but also for device drivers, streams modules, and other components. In many cases binary as well as source compatibility is required. These concerns affect the structure and organisation of the operating system.  Chorus systèmes, 1991 − 2 − February, 1991 Chorus systèmes A New Look at Microkernel-Based UNIX Operating Systems CS/TR-91-7 There is work in progress on a number of fronts to emulate UNIX on top of a microkernel architecture, including the Mach [Gol90], V [Che90], and Amoeba [Tan90] projects. Plan 9 from Bell Labs [Pik91] is a distributed UNIX-like system based on the “minimalist” approach. CHORUS versions V2 and V3 represent the work we have done to solve the problems of compatibility and efficiency. 1.2 The CHORUS Microkernel Technology The Chorus team has spent the past six years studying and experimenting with UNIX “kernelisation” as an aspect of its work in modular, distributed and real-time systems. The first implementation of a UNIX-compatible microkernel-based system was developed during 1984 through 1986 as a research project at INRIA. Among the goals of this project were to explore the feasibility of shifting as much function as possible out of the kernel and to demonstrate that UNIX could be implemented as a set of modules that did not share memory. In late 1986, an effort to create a new version, based on an entirely rewritten CHORUS nucleus, was launched at Chorus systèmes. The current version maintains many of the goals of its predecessor and adds some new ones, including real-time support and − not incidentally − commercial viability. A UNIX subsystem compatible with System V Release 3.2 is currently available, with System V Release 4.0 and 4.4BSD systems under development. The System V Release 3.2 implementation performs comparably with well-established monolithic-kernel systems on the same hardware, and better in some respects. As a testament to its commercial viability, the system has been adopted for use in commercial products ranging from X terminals and telecommunication systems to mainframe UNIX machines. In this paper we examine aspects of the current CHORUS system in terms of its evolution from the previous version. Our focus is on pragmatic issues such as performance and compatibility, as well as considerations of modularity and software engineering. In section 2, we review the previous CHORUS version. Section 3 evaluates the previous version and discusses how the lessons learned from its implementation led to the main design decisions for the current version. The subsequent sections focus on specific aspects of the current design. 2. CHORUS V2 Overview The CHORUS project, while at INRIA, began researching distributed operating systems with CHORUS V0 and V1. These versions proved the viability of a modular, message-based distributed operating system, examined its potential performance, and explored its impact on distributed applications programming. Based on this experience, CHORUS V2 [Arm86, Roz87] was developed. It represented the first intrusion of UNIX into the peaceful CHORUS landscape. The goals of this third implementation of CHORUS were: 1. To add UNIX emulation to the distributed system technology of CHORUS V1; 2. To explore the outer limits of “kernelisation”; demonstrate the feasibility of a UNIX implementation with a minimal kernel and semi-autonomous servers; 3. To explore the distribution of UNIX services; 4. And to integrate support for a distributed environment into the UNIX interface. Since its birth, the CHORUS architecture has always consisted of a modular set of servers running on top of a microkernel (the nucleus) which included all of the necessary support for  Chorus systèmes, 1991 − 3 − February, 1991 Chorus systèmes A New Look at Microkernel-Based UNIX Operating Systems CS/TR-91-7 distribution. The basic execution entities supported by the V2 nucleus were mono-threaded actors running in user mode and isolated in protected address spaces. Execution of actors consisted of a sequence of “processing-steps” which mim