finally

Syed Adnan (sadnan@ucsd.edu)
Tue, 06 Jun 2000 00:15:35 -0700

Name: Syed Adnan
Date: 6-05-00

Exokernel: An OS architecture for
Application-Level resource Management

The motivation of this paper is very similar to the one in SPIN operating system. Paper argues that traditional operating systems limit the performance, flexibility, and functionality of applications by fixing the interface and implementation of operating system abstractions.
Paper argues that application level recourse management can cure these problems. To do this author the paper created a new operating system architecture called Exokernel. This system virtual memory inter-process communication and other system level abstractions are implemented entirely at application level by un-trusted software.
In order to do that Exokernel defines a low level interface. Approach is that lower level primitives are efficient and grant more latitude to implementer to the high level abstraction. One of the key philosophies of the system is to separate protection from management. Exokernel uses three methods to export the recourses securely. First by using secure binding. Second, using visible resource revocation, and finally using an abort protocol.
Paper talks about the motivation for such a system, and then moved on to the design of the system. Paper talks about three different tasks for separating protection from management. First, tracking ownership of recourses. Second, ensuring protection by guarding all resource usage or binding points, and third was revoking access to recourses.
There is talk about implementation and performance of Agies. Paper talks about different issues regarding Agies, its environment where it throws different type of exceptions.
Paper goes on and talk about EXOS. This system manages OS abstractions at application level. IPC abstraction were analyzed during this paper that how Agies handle them.
Extensibility of ExOS is discussed in this paper, RPC and page-table structure were used as an example of this.
Over all this paper argues that Exokernel securely multiplexes available hardware resources among applications.
There are few observations along the papers. First, simplicity leads to efficiency. Second, Exokernel primitives are fast, low-level and secure multiplexing of hardware recourses can be implemented efficiently. Third, traditional OS can be implemented efficiently at application level. Finally, applications can create special-purpose implementation of the abstraction by merely modifying a library.

Name: Syed Adnan
Date: 6-05-00

Extensibility, Safety and Performance in the
SPIN OS

This paper describes the motivation and architecture of SPIN operating system. SPIN provides an extension infrastructure together with a core set of extensible services that allow applications to safely change the operating system's interface and implementation.
The reason (motivation) for such operating system is that there is need to support applications that require demands from operations systems, which are poorly provided by the operating system. Therefore, those applications endure huge amount of un needed overhead because operating system is a general purpose operating system.
Goals of SPIN OS are to provide extensibility, safety and good performance. Extensibility in SPIN is determined by the interface to service and resource that are exported to applications. Safety determines the exposure of applications to the actions of others, and requires that access to be controlled at the same granularity at which extensions are defined.
SPIN OS relies on our techniques implemented at the level of the language or its runtime. Co-location: OS extensions are dynamically linked into the kernel VA space. Co-location enables communication between system and extension code to have low cost. Enforced modularity, logical protection domains, and dynamic call binding are the rest of the three techniques that are being used in this system.
For safety SPIN relies heavily on language and compiler features to ensure safety within kernel. Applications can be written in any language, but code that requires low-latency access to system service is written in the system's safe extension language.
Paper compared many systems with SPIN talking about different methods that other system used, and why those techniques worked, or didn't work. Paper makes a point of having a lot of similarities with Agies system.
Paper talks about capabilities, protections domains where capabilities represent the system resources, and protections domain defines the set of accessible names available to an execution context.
Paper talks about its core services. Extensible memory management is one of these services. This service is responsible for the allocation of virtual address, physical address, and mapping between these addresses spaces. This system decomposes services into three basic components: Physical storage, naming, and translation. Second core service is thread management. This service is responsible for scheduling and synchronization.
Paper goes on and talk about virtual memory management, more on thread management. It does few benchmark measurements comparing SPIN with other system, in which of course SPIN performed better.
Over all paper is well written, relatively easier to understand compare to Agies. I learned few things from this paper; however, in this system and Agies system I felt like programmer needs to know a lot about OS's internal details to be able to write program in this kind of system. I wonder if such a system can catch on like Linux or NT (At least from development point of view)?