The most popular current operating system architectures are monolithic operating system or hybrid operating systems. These architectures provide the interface between application and physical resources through high level abstractions. Physical resources are provided by the kernel and consist of the central processing unit, physical memory, and I/O, etc. These physical resources are not accessed directly by user-level applications, but instead high level abstractions such as virtual memory, process tables, file-systems, etc. are provided for applications to use. These operating systems such as Linux, MacOS and Windows are dependent on the monolithic operating system architecture and inherit the architecture's flaws.
Research has shown that user applications could benefit immensely from the ability to control and view hardware resources directly. Appel and Li showed that the high cost of general-purpose virtual memory primitives reduces the performance of tool applications use such as persistent stores, garbage collectors, and distributed shared memory systems. As well, Cao et al. showed that application-level control over file caching could benefit an applications running time by forty-five percent. Stonebraker showed that inappropriate file-system implementation decisions can have a negative impact on database systems. Harty and Cheriton and Krueger et al. showed that if applications had control over virtual memory policies it would increase application performance. Applications not having control of the signal handling of exceptions reduces performance by a magnitude, demonstrated by Thhekkath and Levy. In response to these problems with the current operating system architecture the need for a new operating system design is apparent.
In response to these limitations of the current operating system architecture, many researchers have been proposing new operating system architectures. Two early papers and classic architectures are Lampson's CAL-TSS and Brinch Hansen's microkernel. Other designs such as the exokernel of VM/370 worked at providing the flexibility needed with virtual machines to virtualize the entire base system using additional hardware support, which operating systems could then implement. Anderson proposed providing application-specific library operating systems would allow the kernel to only focus on the revocation and allocation of hardware resources.. This paper presents three distinct operating system architectures and a combination architecture with the hope that one will provide a suitable replacement or influence for a replacement of the current main stream operating system.
This paper highlights three proposed operating systems and a compromising architecture, all of which aim to address the issues with the current operating system design. The first follows Brinch Hansen's work on a microkernel architecture as Unix as an Application Program proposes running Unix as an application program on top of a microkernel. The second operating system design, Exokernel: An Operating System Architecture for Application-Level Resource Management, is an adaption of the microkernel design focusing on provided minimal abstractions to applications while having the applications themselves take control of high-level abstractions. The third paper reviewed, Rethinking the Library OS from the Top Down, falls under the library operating system design which focuses on having an operating system instance for each application. Finally The Multikernel: A New OS Architecture for Scalable Multicore Systems provides an alternative jumping off point for further hybrid designs while addressing the shortcomings of the previous reviewed designs.
The authors of Unix as an Application Program argue that their design provides benefits such as (i) tailor-ability, (ii) portability, (iii) network accessibility, (iv) extensible, and (v) real-time support. (i) Tailor-ability and (ii) portability are benefits as different operating systems are able to run simultaneously in different applications independently. (iii) As well, a server operating system would not need to be the same as the client operating system which provides more network accessibility. (iv) Extensible is provided as new versions of software can be developed and tested on the same machine as previous versions with security of underlying hardware resources being maintained. (v) Finally for real-time support, the underlying kernel system would not be able to hold the system "hostage" with locks as the application level operating system would hold the lock abilities. In order to achieve these goals the authors divide the normal library operating system into two parts, the Unix server and the Transparent System Call Emulation library.
The authors of Exokernel argue that the traditional operating systems limit the performance, flexibility and functionality of applications by making the operating system abstractions immutable. The authors reason that allowing applications to create their own operating system abstractions would increase flexibility and compatibility of applications as applications could be moved between underlying kernels without heavy code refactoring. Traditional high-level abstractions such as virtual memory, CPU scheduling and inter-process communication are implemented at the application level, allowing the applications to dictate how they wish to optimize these abstractions for their own benefit. The Exokernel focuses on providing a small kernel system that would securely export all hardware resources with minimal abstractions to the untrusted user applications such as a library operating system. The authors propose that their Exokernel adaption of the microkernel design, and an accompanying library operating system would provide the benefits and performance desired from an new operating system architecture.
The authors of Rethinking the Library OS from the Top Down argue that separating the "personality" of the operating system into the application space would be a logical next step to operating system architecture. They define the personality of the operating system as the "the implementation of operating system application programming interfaces and application semantics in which an application would interact with the hardware of an operating system. Early arguments for a library operating system were largely dismissed once the modern virtual machine systems became commonplace due to their ability to run major applications by reusing existing feature rich operating systems. The authors argue that the library operating system architecture should be revisited due to the need for better security and independent system isolation with the large number of applications available to the user. In order to show the benefits of their design, the authors refactored Windows 7 into a library OS called Drawbridge and examined the performance of various applications on Drawbridge and Windows 7. # Operating System Architecture Approaches:
The authors of Unix as an Application Program strived for a more secure and modular system design in which the traditional Unix operating system is divided into two parts. The first part is the underlying hardware resources, and services needed to manage these hardware resources which the design left in the kernel. The second part is the interface for higher-level abstractions of these hardware resources which the design separated from the kernel. The authors were influenced by the increased reliance on the client/server implementation model that is used in network file services, name services and database services. Implementing Unix as an application program was proposed as the next step in operating system design with many advantages such as modularity, network transparency, portability, and extensibility.
The authors of Unix as an Application Program divided the 4.3BSD Unix operating system into two separate and distinct parts. The first is a Unix server which provides the same services and resources that one would expect from a standard Unix kernel such as communication with hardware devices, virtualizing memory, etc. The second portion of the design is the Transparent Emulator Library which is loaded into the address space of each process and provides the system call handler, interrupt handler, file data access.
All communication to the hardware devices is done through a Mach Interprocess Communication which is the link between the Unix Server and the Transparent Emulator Library. This messaging system handles requests as a message that correspond to a normal Unix system call and are the backbone for how the Unix as an Application program works. Each message also gets a C thread assigned to it to allow the message to obtain the arguments for the operation, determine which process requires the operation, and what operation to execute.
The Transparent Emulation Library is loaded into the first process allowing it to be in each process, as memory is allowed to be inherited from parent process to child process in the Mach design. The Transparent Emulation Library is defined as the glue that provides the routines necessary to transform system calls from applications into messages that the Unix Server can use to perform the functionality desired. The library intercepts any system calls from the Mach System Call Redirection Faculty and transforms them into remote procedure calls to pass to the server through messages. Each Transparent Emulation Library also has its own stack allowing it to not be overwritten or manipulated by applications that do their own stack management.
The authors of Exokernel proposed the idea of separating the protection of hardware resources from the management of these hardware resources. The authors followed four design principles that are the basis for their Exokernel operating system architecture.
The authors of Exokernel stated the design must be able to perform three tasks in order to successfully adhere to their proposed principles. (i) The first task was to track the ownership of resources without dictating how a resource is to be used. (ii) The second task was to have a visible resource revocation protocol allowing the library operating system to see and participate in the revocation of resources. (iii) Finally, the third task was for the Exokernel to have the ability of an abort protocol to allow the Exokernel to break secure bindings of an uncooperative library operating system by force.
In order to perform the first task of tracking ownership of hardware resources the Exokernel provides an interface for library operating systems to use, request and release hardware resources. An application can only access a hardware resource that it has been bound with a secure binding, allowing the operating system to multiplex resources securely. A secure binding does not restrict the method of use of a hardware resource but merely provides protection. The mechanism for enforcing a secure binding is done in simple operations that either the kernel or hardware implements. Once an application requests a resource and provided that the set of protection rules has been followed, the secure binding is executed and the application has control over the resource. While a secure binding does not restrict the method of use of a resource its protection rules do dictate what the application can do to a resource. Two examples of protection rules are that an application may read from a disk but may not write to it or that an application can only use a certain percentage of the disk. As well, Exokernel does provide a method of solving conflicting requests for resources which it uses to determine the importance of a request and allocate the resources accordingly.
To perform the second task, the Exokernel system uses physical resource names and visible revocation protocol for most of these resources. During revocation of a resource, a request is sent from the Exokernel to the library operating system. This allows for the library operating system to reduce overhead during its maintenance by saving what is necessary or by responding efficiently to the need to checkpoint or lose a resource. An example would be that a library operating system could avoid saving certain registers during revocation at the end of a designated central processing unit time slice. This visible revocation is possible due to the use of physical names by the Exokernel system. The authors acknowledge that a visible revocation strategy has a higher latency than invisible revocation but the benefits of allowing a library system to react to a revocation call are worth the trade off.
Finally to accomplish the third task, the Exokernel defines a second revocation protocol step for library operating systems that fail to respond efficiently or correctly to the visible revocation protocol. The authors propose a single method of abortion protocol to break the secure bindings of an application when an revocation request turns into an insistent (return the CPU in 20 microseconds) request. The Exokernel will break the secure bindings and inform the library operating system of this action, add a count tracking how many times the application has failed to relinquish resources. A proposed "repossession exception" is the method they choose to inform the application so that it could perform clean up as necessary. Also proposed, is a small set of resources that will not ever be revoked from a library operating system vital information necessary to continue the working state of the application can be stored.
The authors of the Rethinking the Library OS from the Top Down aim to show the possibility of refactoring a monolithic operating system such as Windows 7 into a library operating system. They argue that their refactored library operating system has three benefits over the current commonly used operating system design. (i) First, they believe their library operating system design provides better security isolation between applications and hardware resources through the use of strongly isolated applications and hardware resources. (ii) Second, the authors believe their library operating system design provides better prioritization of application compatibility and portability, allowing applications to be moved between different systems with the inclusion of their library operating system. (iii) Finally, the authors argue that their design provides better independent development of library operating systems and the underlying kernel components. This would allow operating system research topics to be implemented with ease, allowing rapid independent evolution of both the library operating system and the kernel.
In order to accomplish the goal of refactoring a monolithic operating system, the authors prioritize application compatibility and high-level operating system code reuse. The design proposed, Drawbridge, refactors hardware services, user services and application services into its library OS and underlying host operating system. The authors separated their design into a Drawbridge library operating system and a Drawbridge ABI that is implemented by a security monitor and Platform Abstraction Layer.
The Drawbridge library operating system is included in each application that runs in the applications address space. The Drawbridge library operating system contains the API DLLs necessary to run an application in a library operating system architecture. These include application services such as Windows API's, frameworks, rendering engines, UI controls, language runtimes. This allows applications to communicate directly to the Drawbridge library operating system directly and efficiently. Once the Drawbridge library receives a request to interact with the host operating system it may communicate through the remote desktop protocol through the Drawbridge ABI.
The Drawbridge ABI supports standard calls for modifying page-based virtual memory permission bits, multi threading, I/O streams, and child processes. The Drawbridge ABI is implemented with the Security Monitor and Platform Abstraction Layer. The Security Monitor virtualizes the host operating system resources to the library operating system and thus maintains the security between application and hardware resources.
In using this design the authors have successfully refactored Windows 7 into a library operating system with a subset of functioning running applications. The authors claim that this could be the ideal design to easily share applications across different operating systems. As well as functioning ability to develop the underlying operating systems without breaking the applications that run on them.
While the reviewed operating system designs all provide admirable strengths, they are not without their flaws. Due to these following flaws these designs have not met the adequate standard to be adopted as mainstream operating system designs. Although in review of the flaws below, the previously reviewed goals and approach specifics, a combination operating system design may become apparent.
The authors of Unix as an Application Program emphasize the separation of the servers in each application. While this is a positive for security, a negative could be the nature of cooperation between applications. By using the message passing application of this design very frequently, two applications could cause significant performance drops for all applications. This is because the microkernel would be hampered by the processing of the frequent messages which could limit the ability of other applications. One solution could be to have a prioritization of messages between applications and to have a check in place for applications abusing this messaging system. If applications exploit the messaging ability maliciously or just by frequent use, the other applications using the messaging more infrequently would be prioritized in a least recently used fashion. This could also pose problems as applications may need to send messages frequently in bursts but be disregarded until others due to the frequency of messages during those bursts.
The authors also identify problems with how the Unix Server uses the C Thread Library. First, they state that the number of C threads used was larger than the number of kernel threads that were reasonable to use. Secondly, they also identified that the cost of synchronization using the current C thread library is very high. Though the solution of detaching kernel threads from C threads was provided, there could be another problem with the increased use of C threads.
As well, the authors stated that the frequent calls by some Unix applications, such as shell, are cost heavy. The authors did attempt to solve this problem through adding an option of two new memory objects that are allocated at each fork call. These memory objects are a read-only object containing information about the current process and a read-write object that is used to update the state information. Although this is a solution to the design's problem, they did acknowledge this could not be appropriate to tightly coupled multiprocessor or uniprocessor architecture, the former which is popular today.
Although the microkernel was a fledgling design, other designs such as a combination design could provide more significant improvements.
The authors of Exokernel emphasized the ability for applications to define their own high-level abstractions for using hardware resources. While this can be seen as an advantage they fail to acknowledge the potential problems with this design. First, this limits the ability of fledgling application developers to publish their product as new innovations by engineers without the knowledge or background to implement their own high-level abstractions could never come to fruition. The authors do propose the development of libraries to implement these high-level abstractions would be developed and shared among developers freely in a collaborative effort. Though one could argue that another problem could come about in this strategy through errors caused by mistake or malicious activity. While they could not affect the Exokernel themselves, applications do routinely contain sensitive information that could be exploited by these libraries.
Another problem that could occur is an application taking advantage of the visible revocation policy. While the authors do propose an imperative and then forced revocation with a count of infractions, an application developer could hypothetically take advantage of this and manipulate the count of infractions. The Exokernel allows applications to decide their memory resources as long as they are not previously owned. If perchance, manipulating the count of infractions is possible, an application could hog resources until the imperative is received and then release them. While this would not have a destructive impact on the system, nor would it be a certainty, this malicious activity could cost other applications performance that the authors of Exokernel emphatically emphasize.
The authors of Rethinking the Library OS from the Top Down do acknowledge some setbacks from their design. First, their design does not implement all of the standard Windows API functions that an Windows application developer would come to expect. These API functions which normally are used for communicating between applications and the Windows operating system have only a fraction implemented by the refactored Windows 7 design. Many Windows API functions now throw exceptions and the authors predict implementation of the APIs would take significantly more time. This brings in the question of if refactoring a current operating system should be an approach others take.
While the authors state that their refactoring only took two human years, support for printing, support for multi-process applications, and admin applications were not implemented. The support for printing is hard encoded into the windows system and is stated by the authors to cause further dependencies they wish to avoid. The support for multiprocessor applications such as the use of Microsoft Word in Microsoft Outlook, were proposed to have two solutions that could be considered.
Finally, the support for admin applications that affect the host operating system themselves were determined to never be an option for the authors library operating system design. While it is argued that the refactoring without the admin applications would be possible completed, how can the authors be sure as harder problems are left unsolved. It could be argued that the authors underestimate the time it would take to solve these current problems as they themselves did not tackle these problems before their publication. While future research could inevitably prove these problems to be inconsequential, the opposite is not outside the realm of possibilities.
While the reviewed papers do all provide possible solutions for the design of a new operating system, another design takes into account their flaws and builds upon the Library OS and Exokernel designs. The paper The MultiKernel: A New OS Architecture for Scalable Multicore Systems proposes a small kernel design similar to the ones provided in the Exokernel and Library Operating System papers but with a twist. The paper also still emphasizes the need for minimal abstractions to be provided by the kernel and some high-level abstractions to be implemented by a library operating system.
The Multikernel design uses a set of kernels to each control individual hardware resources or small groups of hardware resources. The specific hardware resources that the microkernels handle include specific cores, memory sections, I/O devices etc. The multikernels do still provide minimalistic kernel functions to the library operating system but do not limit the library operating system ability to define its own high level abstractions.
The library operating systems communicate to the multikernels or to each other through message passing. In order to allocate hardware resources the library operating systems message the kernel for a request to access. In order to run specific restricted kernel operations, such as creating a new process, a message is sent from the library operating system to the kernel requesting the execution of the operation. The message capability between library operating systems could solve the lack of multi-process communication which was a highlighted problem from Rethinking the Library OS from the Top Down. The library operating systems could be able to communicate and cooperate as desired by the example of using Microsoft Word in Microsoft Outlook.
The Multikernel minimal abstraction design adheres to the desire to separate the kernel from the library operating system as was desired in the Library Operating System. This design also still exposes the hardware resources to the library operating system as desired in the Exokernel. Additionally, while Exokernel relies solely on the applications themselves to define the abstractions, Multikernel does provide some basic abstractions that could make it easier to develop and maintain libraries for higher-level abstractions. The design also would suggest better multiprocessor performance as applications can message the specific cores that they wish to utilize which was a problem described in Unix as an Application Program.
The authors do acknowledge that they were not able to fully evaluate the Multikernel architecture with complex application workloads or using higher-level operating systems file-system/storage system. Nor have they been able to evaluate the scalability of the Multikernel but one could predict that by its very nature that it would be scalable due to the Multikernel design being modular.
Exokernel, Unix as an Application Program, and Rethinking the Library OS from the Top Down all would be an improvement to the current operating systems but do not meet all the needs for a production operating system. Thus, it would be reasonable to conclude that it would be more beneficial to look at modifications that include benefits from multiple proposed designs in a combination fashion as the Multikernel attempted. As more researchers embrace the idea of transforming these designs by picking and choosing features they need for their specification a better more fully developed and polished operating system could be achieved. Even while the Multikernel or other hybrid kernel approaches may not be the final solution to the problem. Inspiration should be taken from a combination of operating system designs for any future operating systems research and development.