Back

Exokernel: an operating system architecture for application-level resource management

D. EnglerM. KaashoekJames O'ToolJeffrey J. Weston

article1995SOSP1,541 citations

Proposes a minimalist operating system architecture that safely delegates hardware management to untrusted library operating systems, enabling applications to customize low-level resource abstractions and achieve order-of-magnitude performance gains over monolithic kernels.

Listen

Traditional operating systems centralize hardware management by imposing fixed, high-level abstractions like generic virtual memory, process models, and file systems. This rigid design forces all software into one-size-fits-all trade-offs, degrading application performance, restricting developer flexibility, and preventing specialized optimizations needed by modern data-intensive systems. The article evaluates the exokernel architecture, an alternative design that strips the kernel down to a minimal layer responsible only for securely multiplexing physical hardware, while shifting traditional operating system abstractions entirely into untrusted application-level libraries.

To demonstrate this concept, the authors built a prototype system consisting of Aegis, an exokernel that exports fine-grained hardware resources using physical naming and visible revocation protocols, and ExOS, a library operating system running in application space. The authors evaluated the system on MIPS-based workstations against Ultrix 4.2, a mature and well-tuned monolithic operating system, across benchmarks measuring primitive system calls, trap and exception handling, inter-process communication, and virtual memory operations.

The experimental findings show substantial performance advantages across several dimensions. First, primitive kernel operations in Aegis executed roughly 10 to 100 times faster than in Ultrix, with exception handling dispatching in about 2 microseconds compared to 200 to 294 microseconds in the baseline system. Second, application-level inter-process communication built on Aegis was between 10 and 79 times faster than Ultrix, and protected control transfers outperformed the fastest published microkernel results by a factor of 3. Third, high-level virtual memory benchmarks ran up to an order of magnitude faster under the library operating system, demonstrating that delegating core management to user level does not introduce performance penalties for compute tasks like matrix multiplication.

These results show that low-level hardware multiplexing is practical and highly efficient. By giving software direct control over resource policies, developers can implement custom memory management and communication mechanisms that drastically reduce overhead and eliminate bottlenecks. Because the exokernel avoids complex abstractions within privileged space, the underlying kernel remains simple, highly maintainable, and adaptable to emerging hardware interfaces.

Organizations developing high-performance software should consider decoupled, application-level resource management architectures for systems that suffer from conventional operating system overheads. Moving forward, developers and researchers should implement more comprehensive library operating systems that include secondary storage, full swapping support, and dynamic linking to prevent binary bloat.

Readers should note that the evaluation is based on an early-stage prototype tested on a single hardware family with a very small user base. Aegis currently lacks complete storage management, and the architecture relies on conventional trust models to handle misbehaving or uncooperative applications. While confidence in the benchmarked performance gains is high, broader real-world validation is necessary before applying the architecture to mission-critical, large-scale production environments.

Massachusetts Institute of Technologycommunicationhardware resourceslibrariesexokernel architectureapplication-level resource managementoperating system architecture
Engler et al (1995).pdf
  • Paper: Xen and the art of virtualization, P. Barham et al. (2003). Read this to see how the principles of minimal privileged control and safe resource multiplexing evolve into paravirtualization hypervisors.
  • Paper: seL4: formal verification of an OS kernel, Gerwin Klein et al. (2009). Read this to explore how formal verification can mathematically prove the correctness and security isolation of minimal microkernel architectures.
  • Paper: The Click modular router, Robert Morris et al. (1999). Read this to learn how modular, fine-grained control over packet processing mirrors exokernel resource management in network software.
  • Paper: Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center, Benjamin Hindman et al. (2011). Read this to understand how the exokernel philosophy of thin resource multiplexing and decoupled policy is applied at the datacenter cluster scale.
  • Paper: Live migration of virtual machines, Christopher J. Clark et al. (2005). Read this to discover how hypervisor-level physical resource management enables live migration of running operating system instances.
Cover for Exokernel: an operating system architecture for application-level resource management

Abstract

We describe an operating system architecture that securely multiplexes machine resources while permitting an unprecedented degree of application-specific customization of traditional operating system abstractions. By abstracting physical hardware resources, traditional operating systems have significantly limited the performance, flexibility, and functionality of applications. The exokernel architecture removes these limitations by allowing untrusted software to implement traditional operating system abstractions entirely at application-level.

We have implemented a prototype exokernel-based system that includes Aegis, an exokernel, and ExOS, an untrusted application-level operating system. Aegis defines the low-level interface to machine resources. Applications can allocate and use machine resources, efficiently handle events, and participate in resource revocation. Measurements show that most primitive Aegis operations are 10–100 times faster than Ultrix, a mature monolithic UNIX operating system. ExOS implements processes, virtual memory, and inter-process communication abstractions entirely within a library. Measurements show that ExOS's application-level virtual memory and IPC primitives are 5–50 times faster than Ultrix's primitives. These results demonstrate that the exokernel operating system design is practical and offers an excellent combination of performance and flexibility.

Topics

communicationhardware resourceslibrariessoftwaresystem architecturessystems designmultiplexerarchitecture designslinuxmicrokernel

Keywords

exokernel architectureapplication-level resource managementoperating system architecturelibrary operating systemsvirtual memory systemmonolithic UNIX operating system

Table of Contents

  • 1 Introduction
  • 2 Motivation for Exokernels
  • 2.1 The Cost of Core Abstractions
  • 2.2 Exokernels: An End-to-End Argument
  • 2.3 Library Operating Systems
  • 3 Exokernel Design
  • 3.1 Design Principles
  • 3.2 Secure Resource Multiplexing
  • Multiplexing Physical Memory
  • Multiplexing a Frame Buffer
  • Multiplexing the Network
  • 3.3 Revocation
  • Revocation and Physical Naming
  • The Abort Protocol
  • 3.4 Summary
  • 4 Aegis: an Exokernel
  • 4.1 Experimental Configuration
  • 4.2 Aegis Overview
  • 4.2.1 Processor Time Slices
  • 4.2.2 Processor Environments
  • 4.3 Basic Costs
  • 4.4 Exceptions
  • 4.5 Address Translations
  • 4.6 Protected Control Transfers
  • 5 ExOS: an extensible OS
  • 5.1 Fast IPC Abstractions
  • 5.2 Application-level Virtual Memory
  • 5.3 Summary
  • 6 Discussion
  • 7 Related work
  • 8 Conclusion
  • Acknowledgments
  • References

Knowls

  1. Knowl 1 — Exokernel Architecture and Design Principles

    model/method

    The exokernel architecture separates hardware protection from resource management by moving traditional operating system abstractions (such as virtual memory, processes, file systems, and inter-process communication) into untrusted, application-level library operating systems (LibOSes). The exokernel acts as a thin multiplexer whose sole responsibility is to track resource ownership, guard usage points to enforce security, and revoke access.

    The exokernel design follows three core principles:

    1. Expose Hardware: Safely export physical hardware resources and privileged instructions (such as physical memory pages, CPU contexts, DMA channels, and TLBs) directly to untrusted applications in a fine-grained manner, wrapping privileged operations in lightweight system calls that verify resource ownership.
    2. Expose Names: Identify machine resources using physical names (such as physical page numbers) rather than virtualized names. Physical naming enables applications to exploit hardware-specific properties (e.g., allocating specific physical pages to avoid direct-mapped cache conflicts) without kernel translation layers.
    3. Expose Events: Provide visible, application-level notifications for system events (such as resource revocation requests, hardware traps, and timer interrupts), allowing applications to make domain-specific allocation and context-saving decisions.

  2. Knowl 2 — Secure Bindings for Decoupled Protection and Authorization

    model/method

    Secure bindings decouple high-level access authorization decisions from low-level hardware protection checking. While complex access-control policies (e.g., file permissions or directory hierarchies) are computed by untrusted application-level servers or libraries, the exokernel enforces the resulting access rights using low-overhead protection mechanisms at resource usage points.

    Mechanisms used to implement secure bindings include:

    • Self-Authenticating Capabilities: When an application allocates a hardware resource (such as a physical memory page), the exokernel creates a secure binding recording the owner and read/write capabilities. Future operations (such as inserting a mapping into the hardware TLB or initiating DMA) require the presenting application to supply the valid capability. Page capabilities incur low space overhead (e.g., two 64-bit capabilities per 4-kilobyte page represents a 0.4%0.4\% overhead).
    • Hardware Tagging: On hardware supporting hardware tags (such as ownership tags on individual frame-buffer pixels or disk sector labels), applications access devices directly while the hardware automatically validates access rights.
    • Packet Filters: For devices lacking fine-grained hardware demultiplexing (such as network interfaces), the exokernel executes user-downloaded packet filters to inspect packet headers and route incoming packets directly to the recipient application without embedding protocol logic into the kernel.

  3. Knowl 3 — Visible Resource Revocation and the Abort Protocol

    model/method

    The exokernel manages resource reclamation through a visible revocation protocol rather than deallocating resources invisibly:

    1. Visible Revocation Dialogue: When resources become scarce, the exokernel requests that an application relinquish a given quantity of resources (e.g., "return a memory page"). Because resources use physical names, the application selects which specific resource to release, updates its internal bookkeeping (e.g., removing references in its user-level page tables), writes any modified state to disk if necessary, and calls the exokernel to release the resource.
    2. The Abort Protocol: To handle uncooperative or slow applications, a revocation request transitions into a time-bounded imperative (e.g., return the resource within 50 μs\mu\text{s}). If an application fails to comply, the exokernel forcibly repossesses the resource.
    3. Repossession Handling: The exokernel records the forced deallocation in a per-application repossession vector and delivers a repossession exception to the application. If the resource contains state (such as a physical memory page), the exokernel saves it into backing store pre-registered by the application in its repossession vector.
    4. Guaranteed Resources: To prevent repossession from causing unrecoverable failures, each application is guaranteed a small number of non-repossessable physical memory pages (typically 5–10 pages) to store bootstrap structures, exception handlers, and page-table roots.

  4. Knowl 4 — Processor Time-Slice Representation and Processor Environments in Aegis

    model/method

    In the Aegis exokernel, the CPU is represented as a space-multiplexed linear vector where each element corresponds to a discrete time-slice allocated at clock granularity. Scheduling operates via round-robin cycling through the vector. The vector index encodes an ordering and an approximate upper bound on dispatch latency, allowing applications to trade latency for throughput (e.g., an interactive program allocates equidistant slices across the vector, while a batch computation allocates contiguous slices to reduce context-switching frequency).

    All resource consumption and event routing are managed through an Aegis processor environment, which defines four distinct event contexts:

    • Exception context: Starting program counter addresses and user-space register save area pointers for hardware traps.
    • Interrupt context: Program counters and register-save regions for handling hardware interrupts, including separate start-time-slice and end-time-slice vectors for timer interrupts.
    • Protected Entry context: Designated entry program counter addresses for synchronous and asynchronous control transfers from other environments, with access control managed entirely by the target application.
    • Addressing context: Guaranteed address translations for bootstrapping, page-table roots, exception stacks, the hardware address space identifier, processor status register, and a software TLB process hash tag.

  5. Knowl 5 — Hardware Exception Forwarding in Aegis

    algorithm

    Aegis forwards all hardware exceptions directly to user-level application handlers without using mapped kernel data structures or taking kernel TLB faults. On a MIPS architecture, Aegis dispatches an exception in 18 instructions using the following procedure:

    Input: Hardware exception triggered during application execution
    Output: Execution resumed at application-level exception handler
    1. Save three scratch registers into the application's designated save area using physical addresses to avoid TLB faults.
    2. Read the hardware exception program counter, the faulting virtual address, and the exception cause register.
    3. Use the exception cause value to perform an indirect jump to the application-specified handler address.
    4. Resume execution in user mode with interrupts enabled and all exception state accessible in user memory for state reconstruction.

  6. Knowl 6 — Application-Level Virtual Memory and Software TLB (STLB) in Aegis

    model/method

    Aegis supports application-level virtual memory (AVM) through a combination of pinned guaranteed mappings and a large kernel Software TLB (STLB):

    • Bootstrapping via Guaranteed Mappings: The virtual address space is split into two regions. The first holds normal application code and data. The second holds page tables, exception stacks, and exception code. Mappings in the second region can be pinned as guaranteed mappings; TLB misses on these addresses are resolved automatically by Aegis, eliminating recursive page faults during exception handling.
    • Software TLB (STLB): To absorb hardware TLB capacity misses without invoking user-level upcalls on every miss, Aegis provides a direct-mapped STLB containing 4096 entries (8 bytes per entry, 32 KB total) residing in unmapped physical memory. Each process environment is assigned an 11-bit tag randomly drawn from [0,211−1][0, 2^{11} - 1]. Aegis hashes virtual addresses by XORing them with this tag. On an STLB hit, Aegis refills the hardware TLB in 18 instructions (2–3 μs\mu\text{s} faster than user-level upcalls). On an STLB miss, the fault is forwarded to the application's virtual memory handler, which checks its own page table, constructs a TLB entry and capability, and requests insertion via a privileged system call.

  7. Knowl 7 — Synchronous and Asynchronous Protected Control Transfers

    model/method

    Aegis provides protected control transfer primitives as the low-level foundation for inter-process communication (IPC). A protected control transfer atomically changes the program counter to an authorized entry point in the callee environment, installs the callee's addressing context (address space identifier, address space tag, and processor status word), and transfers the CPU time-slice.

    Aegis implements two variants:

    • Synchronous Protected Control Transfer: Donates the current time-slice and all future scheduled instances of that time-slice to the callee until the callee explicitly executes a matching synchronous return call back to the caller.
    • Asynchronous Protected Control Transfer: Donates only the remainder of the current time-slice to the callee.

    Aegis guarantees that the control transfer is atomic and preserves all user-visible general-purpose registers across the transfer. This allows registers to serve as direct message-passing buffers without kernel mediation. On a MIPS processor, the synchronous protected control transfer executes in 30 instructions.

  8. Knowl 8 — Application-Level IPC Primitives in ExOS

    model/method

    The ExOS library operating system implements traditional inter-process communication mechanisms entirely in user space above the Aegis exokernel primitives:

    • Pipes: Implemented as shared-memory circular buffers. When a process attempts to read from an empty buffer or write to a full buffer, it yields the CPU to the consumer or producer using the Aegis yield system call. ExOS supports an optimized variant (pipe-opt) that inlines read and write library routines directly into the application.
    • Shared Memory Synchronization (shmem): Two processes ping-pong a shared counter by calling the exokernel yield system call to alternate execution.
    • Lightweight Remote Procedure Call (LRPC): Built on synchronous protected control transfers. ExOS provides two implementations: standard untrusted lrpc, which saves and restores all general-purpose callee-saved registers on the client side, and trusted tlrpc, where the client only saves and restores the stack pointer, relying on the trusted server environment to restore whatever registers it modifies.

  9. Knowl 9 — Latency Comparison of Aegis Primitives vs. Ultrix 4.2

    data/table

    Primitive operation benchmarks were measured on DECstation 2100 (12.5 MHz MIPS, 12 MB memory) and DECstation 3100 (16.67 MHz MIPS, 24 MB memory) systems running Aegis and Ultrix 4.2 in single-user mode. Times are reported in microseconds (μs\mu\text{s}).

    Machine OS Null Procedure Syscall (getpid) Unaligned Access Overflow Trap Protection Trap
    DEC2100 Ultrix4.2 0.57 32.2 n/a 272.0 294.0
    DEC2100 Aegis 0.56 3.2 / 4.7 2.8 2.8 3.0
    DEC3100 Ultrix4.2 0.42 33.7 n/a 200.0 242.0
    DEC3100 Aegis 0.42 2.9 / 3.5 2.1 2.1 2.3

    Aegis system calls have two paths: without stack (faster) and with stack (slower). Unaligned access exceptions in Ultrix are handled internally by kernel fixup routines and cannot be caught directly by applications. Hardware exception dispatch in Aegis is approximately two orders of magnitude faster than in Ultrix 4.2 because Aegis forwards traps in 18 instructions without kernel TLB miss handling overhead.

    Uni-directional protected control transfer overhead in Aegis was measured at 2.89 μs\mu\text{s} on DEC2100 and 2.2 μs\mu\text{s} on DEC3100, compared to normalized L3 RPC results of 9.1 μs\mu\text{s} and 6.67 μs\mu\text{s} on an Intel 486/50 MHz platform.

  10. Knowl 10 — Performance of ExOS Virtual Memory and IPC Primitives vs. Ultrix 4.2

    data/table

    ExOS application-level virtual memory and IPC implementations were evaluated against Ultrix 4.2 on DECstation 2100 and DECstation 3100 platforms. All times are in microseconds (μs\mu\text{s}).

    Inter-Process Communication Microbenchmarks:

    Machine OS pipe pipe-opt shmem lrpc tlrpc
    DEC2100 Ultrix4.2 334.0 n/a 334.0 680.0 n/a
    DEC2100 Aegis/ExOS 30.9 24.8 12.4 13.9 8.6
    DEC3100 Ultrix4.2 231.0 n/a 231.0 457.0 n/a
    DEC3100 Aegis/ExOS 22.6 18.6 9.3 10.4 6.4

    Virtual Memory Benchmarks (Appel and Li Suite):

    Machine OS dirty (un)prot1 prot100 unprot100 trap appel1 appel2
    DEC2100 Ultrix4.2 n/a 51.6 175.0 175.0 297.0 438.0 392.0
    DEC2100 Aegis/ExOS 17.5 32.5 213.0 275.0 13.9 74.4 45.9
    DEC3100 Ultrix4.2 n/a 47.8 140.0 140.0 240.0 370.0 325.0
    DEC3100 Aegis/ExOS 13.1 24.4 156.0 206.0 10.1 55.0 34.0

    ExOS untrusted lrpc is 44–49 times faster than pipe-emulated RPC on Ultrix, while trusted tlrpc is 71–79 times faster. In virtual memory tests, trap handling on ExOS is 21–24 times faster than Ultrix, and composite page-fault benchmarks (appel1 and appel2) run 5 to 10 times faster on ExOS. Ultrix outperforms ExOS on bulk contiguous protection changes (prot100 and unprot100) by 20%–60% due to ExOS needing to update both the Aegis STLB and the user-level page table.

Coverage note — Omitted brief passing references to the Glaze exokernel and PhOS library operating system for SPARC multiprocessors, which were not evaluated or detailed in the text.

References

  1. 1.M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and M. Young. Mach: a new kernel foundation for UNIX development. Proc. Summer 1986 USENIX Conference, pages 93–112, July 1986.
  2. 2.T.E. Anderson. The case for application-specific operating systems. In Third Workshop on Workstation Operating Systems, pages 92–94, 1992.
  3. 3.T.E. Anderson, B.N. Bershad, E.D. Lazowska, and H.M. Levy. Scheduler activations: Effective kernel support for the user-level management of parallelism. In Proc. Thirteenth Symposium on Operating System Principles, pages 95–109, October 1991.
  4. 4.A.W. Appel and K. Li. Virtual memory primitives for user programs. In Proceedings of the Fourth International Conference on ASPLOS, pages 96–107, Santa Clara, CA, April 1991.
  5. 5.K. Bala, M.F. Kaashoek, and W.E. Weihl. Software prefetching and caching for translation lookaside buffers. In Proceedings of the First Symposium on OSDI, pages 243–253, November 1994.
  6. 6.B. N. Bershad. High performance cross-address space communication. Technical Report 90-06-02 (PhD Thesis), University of Washington, June 1990.
  7. 7.B.N. Bershad, C. Chambers, S. Eggers, C. Maeda, D. McNamee, P. Pardyak, S. Savage, and E. Sirer. SPIN - an extensible microkernel for application-specific operating system services. TR 94-03-03, Univ. of Washington, February 1994.
  8. 8.B.N. Bershad, D.D. Redell, and J.R. Ellis. Fast mutual exclusion for uniprocessors. In Proc. of the Conf. on Architectural Support for Programming Languages and Operating Systems, pages 223–237, October 1992.
  9. 9.Pei Cao, Edward W. Felten, and Kai Li. Implementation and performance of application-controlled file caching. In Proceedings of the First Symposium on OSDI, pages 165–178, November 1994.
  10. 10.Jeffrey S. Chase, Henry M. Levy, Michel Baker-Harvey, and Edward D. Lazowska. How to use a 64-bit virtual address space. Technical Report TR 92-03-02, University of Washington, 1992.
  11. 11.D. Cheriton and K. Duda. A caching model of operating system kernel functionality. In Proceedings of the First Symposium on Operating Systems Design and Implementation, November 1994.
  12. 12.D. R. Cheriton. An experiment using registers for fast message-based interprocess communication. Operating Systems Review, 18:12–20, [10] 1984.
  13. 13.D. R. Cheriton. The v kernel: A software base for distributed systems. IEEE Software, 1(2):19–42, April 1984.
  14. 14.R. J. Creasy. The origin of the VM/370 time-sharing system. IBM J. Research and Development, 25(5):483–490, September 1981.
  15. 15.H. Custer. Inside Windows/NT. Microsoft Press, Redmond, WA, 1993.
  16. 16.P. Deutsch and C.A. Grant. A flexible measurement tool for software systems. Information Processing 71, 1971.
  17. 17.Richard Draves. Private Communication, December 1994.
  18. 18.Peter Druschel, Larry L. Peterson, and Bruce S. Davie. Experiences with a high-speed network adaptor: A software perspective. In SIGCOMM‘94, pages 2–13, 1994.
  19. 19.Per Brinch Hansen. The nucleus of a multiprogramming system. Communications of the ACM, 13(4):238–241, April 1970.
  20. 20.J.H. Hartman, A.B. Montz, David Mosberger, S.W. O’Malley, L.L. Peterson, and T.A. Proebsting. Scout: A communication-oriented operating system. Technical Report TR 94-20, University of Arizona, Tucson, AZ, June 1994.
  21. 21.K. Harty and D.R. Cheriton. Application-controlled physical memory using external page-cache management. In Proceedings of the Fifth International Conference on ASPLOS, pages 187–199, October 1992.
  22. 22.W.C. Hsieh, M.F. Kaashoek, and W.E. Weihl. The persistent relevance of IPC performance: New techniques for reducing the IPC penalty. In Fourth Workshop on Workstation Operating Systems, pages 186–190, October 1993.
  23. 23.J. Huck and J. Hays. Architectural support for translation table management in large address space machines. In Proceedings of the 19th International Symposium on Computer Architecture, 1992.
  24. 24.SPARC International. The SPARC Architecture Manual Verson 8. Prentice Hall, Englewood Cliffs, New Jersey 07632, 1992.
  25. 25.Keith Krueger, David Loftesness, Amin Vahdat, and Thomas Anderson. Tools for development of application-specific virtual memory management. In Proceedings of OOPSLA, pages 48–64, October 1993.
  26. 26.B. W. Lampson. Hints for computer system design. In Proceedings of the Eighth ACM Symposium on Operating Systems Principles, pages 33–48, December 1983.
  27. 27.B.W. Lampson. On reliable and extendable operating systems. State of the Art Report, Infotech, 1, 1971.
  28. 28.B.W. Lampson and R.F. Sproull. An open operating system for a single-user machine. Proceedings of the Seventh ACM Symposium on Operating Systems Principles, pages 98–105, 1979.
  29. 29.Jochen Liedtke. Improving IPC by kernel design. In Proceedings of the Fourteenth ACM Symposium on Operating Systems Principles, pages 175–188, 1993.
  30. 30.Steven Lucco. High-performance microkernel systems (abstract). In Proc. of the first Symp. on OSDI, November 1994.
  31. 31.H. Massalin. Synthesis: an efficient implementation of fundamental operating system services. PhD thesis, Columbia University, 1992.
  32. 32.J.C. Mogul, R.F. Rashid, and M.J. Accetta. The packet filter: An efficient mechanism for user-level network code. In Proceedings of 11th SOSP, pages 39–51, Austin, TX, November 1987.
  33. 33.David Nagle, Richard Uhlig, Tim Stanley, Stuart Sechrest, Trevor Mudge, and Richard Brown. Design tradeoffs for software-managed TLBs. 20th Annual International Symposium on Computer Architecture, pages 27–38, 1993.
  34. 34.G.J. Popek et al. UCLA data secure UNIX. In Proc. of the 1979 National Computer Conference, pages 355–364, 1979.
  35. 35.D. Probert, J.L. Bruno, and M. Karzaorman. SPACE: A new approach to operating system abstraction. In IWOOS, 1991.
  36. 36.R.F. Rashid and G. Robertson. Accent: A communication oriented network operating system kernel. Proceedings of the Eighth ACM Symposium on Operating Systems Principles, pages 64–75, December 1981.
  37. 37.D.D. Redell, Y.K. Dalal, T.R. Horsley, H.C. Lauer, W.C. Lynch, P.R. McJones, H.G. Murray, and S.C. Purcell. Pilot: An operating system for a personal computer. Communications of the ACM, 23(2):81–92, February 1980.
  38. 38.Theodore H. Romer, Dennis Lee, Brian N. Bershad, and J. Bradley Chen. Dynamic page mapping policies for cache conflict resolution on standard hardware. In Proceedings of the First Symposium on OSDI, pages 255–266, November 1994.
  39. 39.M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrmann, C. Kaiser, S. Langlois, P. Leonard, and W. Neuhauser. Chorus distributed operating system. Computing Systems, 1(4):305–370, 1988.
  40. 40.J.H. Saltzer, D.P. Reed, and D.D. Clark. End-to-end arguments in system design. Trans. on Computer Systems, 2(4):277–288, November 1984.
  41. 41.Margo Seltzer et al. An introduction to the architecture of the VINO kernel, November 1994.
  42. 42.R.L. Sites. Alpha axp architecture. Comm. of the ACM, 36(2), February 1993.
  43. 43.M. Stonebraker. Operating system support for database management. CACM, 24(7):412–418, July 1981.
  44. 44.A.S. Tanenbaum, R. van Renesse, H. van Staveren, G. Sharp, S.J. Mullender, A. Jansen, and G. van Rossum. Experiences with the Amoeba distributed operating system. Communications of the ACM, 33(12):46–63, December 1990.
  45. 45.C. A. Thekkath and Henry M. Levy. Hardware and software support for efficient exception handling. In Sixth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS-VI), 1994.
  46. 46.R. Wahbe, S. Lucco, T. Anderson, and S. Graham. Efficient software-based fault isolation. In Proceedings of the Fourteenth ACM Symposium on Operating Systems Principles, pages 203–216, 1993.
  47. 47.Carl A. Waldspurger and William E. Weihl. Lottery scheduling: Flexible proportional-share resource management. In Proceedings of the First Symposium on Operating Systems Design and Implementation, pages 1–11, 1994.
  48. 48.W. Wulf, E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, and F. Pollack. HYDRA: The kernel of a multiprocessing operating system. Communications of the ACM, 17(6):337–345, July 1974.

Citation

MLA
Engler, D. R., et al. “Exokernel”. Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles - SOSP '95, 1995, pp. 251–66, https://doi.org/10.1145/224056.224076.
APA
Engler, D. R., Kaashoek, M. F., & O'Toole, J. (1995). Exokernel. Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles - SOSP '95, 251–266. https://doi.org/10.1145/224056.224076
Chicago
Engler, D. R., M. F. Kaashoek, and J. O'Toole. 1995. “Exokernel”. Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles - SOSP '95, 251–66. https://doi.org/10.1145/224056.224076.
Harvard
Engler, D.R., Kaashoek, M.F. and O'Toole, J. (1995) “Exokernel”, Proceedings of the fifteenth ACM symposium on Operating systems principles - SOSP '95. ACM Press, pp. 251–266. Available at: https://doi.org/10.1145/224056.224076.
Vancouver
1. Engler DR, Kaashoek MF, O'Toole J (1995) Exokernel. In: Proceedings of the fifteenth ACM symposium on Operating systems principles - SOSP '95. ACM Press, pp 251–266

BibTeX

@inproceedings{Engler_1995, series={SOSP ’95}, title={Exokernel: an operating system architecture for application-level resource management}, url={http://dx.doi.org/10.1145/224056.224076}, DOI={10.1145/224056.224076}, booktitle={Proceedings of the fifteenth ACM symposium on Operating systems principles  - SOSP ’95}, publisher={ACM Press}, author={Engler, D. R. and Kaashoek, M. F. and O’Toole, J.}, year={1995}, pages={251–266}, collection={SOSP ’95} }
Metadata:Crossref

Access the Paper

This paper is available from its original source. Click below to access the PDF.

Open PDF