This paper gives a complete view of extensible operating system SPIN by addressing its motivation, involved techniques and performance. By provide a specifiable base system, SPIN allows applications to customize the underlying services dynamically to satisfy their needs and improve performance. The key of SPIN system architecture is the method of combining applications¡¯ extension with the system safely, so that efficient, fine-grained control over resources and communication becomes applicable. Also a set of core services are provided by SPIN to manage memory and processor resources and exported with fine-grained interfaces for application to adapt. SPIN and its extensions are written in Modula-3 language to enforce type safety and protect kernel from extensions. In the end of this paper, performance of SPIN is explained from many perspectives. From all the result, we can see extensible operating system presents competitive performance for letting applications to tailor the system services. The paper is valuable since it summarized the key technology involved in SPIN and evaluated it by doing variety of testing. Good thing is making possible for applications to define the system service they need. Bad thing is the safety and performance problems. SPIN system solves it by depending co-location mechanism, language level protection and etc. But I doubt whether it can eliminate authorized malicious code to grab resources and execute without stopping.
(note: my postscript viewer would not display page 13 of this paper) This paper provides an introduction to SPIN. The format of the paper was very typical for an implementation paper, however I still found that the text was difficult to follow at times. The main concept behind SPIN is to allow for operating system extensibility with minimal cost, where cost relates to a variety of factors including the execution speed, executable size, and type safety within the extensions. Using these extensions, one can blur the line between kernel and user space in order to allow for a larger degree of flexibily for each type of program (e.g., a web server can use it's own file caching scheme in order to provide for optimal reponse times). I find this idea to be very appealing from a programmers perspective in that it would allow user applications to have a much higher level of system control. Certainly there are a wide variety of applications that could benefit from this. However, I feel that there are also a variety of security concerns that arrise with this type of system (e.g., Since a capability is equivilent to a pointer, what would prevent someone from forging a pointer?). While this paper was in no way trying to be a security paper, I feel that the security issues would ultimately need to be addressed before such an operating system could achieve real world viability. Beyond the security concerns, I generally liked the approach presented in this paper.
This paper by Barshad et al provides an overview of the design and implementation of the SPIN operating system. SPIN uses an event-based model to achieve a loose coupling between interacting modules. The idea is to provide an efficient yet safe means of extending the services provided by the OS. In addressing the safety issue, the authors chose to leverage the features of Modula-3 that allow the programmer to explicitly limit access (hiding) to various features of a module. The Modula-3 compiler can also ensure that usage and extensions of modules obey the type checking rules thereby providing a degree of safety. The authors resign the discussion of a higher-level notion of safety/enforcement of semantic contracts etc. to a brief mention of guards and an authorization model. That said, the asynchronous model of dispatch and a layered approach to the construction of the event-based extensions seems to satisfy the requirement that the consequences of any such violation is restricted to a limited hierarchy of components. The main feature of SPIN that provides efficiency is colocation of extension code within the kernel address space. This allows application specific behavior to be provided at the expense of only an in-kernel procedure call. While other models of extensibility provide some safety by restricting access across address-spaces, SPIN relies on Modula-3's dynamic linking, type checking and encapsulation facilities to ensure safe interaction between user extension and the kernel. As such, SPIN seems like a variant of the Pilot system described briefly. While the authors point out that the SPIN uses a hybrid approach of virtual address spaces with language features for protection, their case is weakened by the fact that in the examples/benchmarks presented all the extensions are colocated with the kernel. Furthermore, little space is devoted to scalability and the argument that the principal bottleneck in the processing of multiple handlers is only the dispatcher is unconvincing.
This paper describes the architecture and performance of SPIN, which is an extensible operating system. According to the paper extensions allow an application to specialize the underlying operating system to achieve performance and functionality. This paper highlights the point of developing SPIN operating System that provides extensibility, safety and good performance. SPIN uses four techniques co-location, enforced modularity, logical protection domains and dynamic call binding of languages. Paper describes the need of language features to used for SPIN OS .The traditional OS are not well suited for specialization and good performance. The paper also gives the brief overview of some of the systems like Hydra, use of micro kernel for building extensible system, and aegis. And author points out the disadvantages of the earlier systems. The design of the SPIN depends on the language’s safety and encapsulation like interfaces, type safety and automatic storage management. Later part of the paper explains the concept of protection model i.e. set of operations that can be applied to resources. In this portion of the paper Authors explains the concept of the capabilities and very well outshines the method implemented in traditional OS i.e. using hardware with the method of implementing it with pointers in SPIN. In SPIN the naming and protection interface is at the level of language not at the virtual memory level. The extension model is based on the events. The paper also throws a light on the some of the core services implementation in SPIN, like Extensible memory management and Extensible thread management. The paper presents the concept where the core services are trusted i.e. they must be executed according to there specifications in the interfaces.In the end of the paper system performance issues are touched .The performance of SPIN is evaluated from four prospective: System Size, Microbenchmarks, Networking and End-to-end performance.
This paper gives an overview of the SPIN OS. The goal of SPIN was/is to have an OS where system services can be efficiently tuned to Application requirements in a standard way. The authors note that all OSs are extensible to some degree, but in general such extensibility at run time comes with high overhead costs- with the alternative being kernel modification and recompiation. A problem is that OSs typically try to provide the most generally useful optimizations which may not be correct for all applications. SPIN's approach is to allow extensions to be added on to the system at runtime. The extensions handle specific fine grained events which are explicitly exported by the OS. Extensions are linked into kernel address space where they can be accessed in general with the speed of a function call. Safety is attained through "Enforced modularity" of the language used: modula-3. The OS itself and all OS extensions must be implemented in this language, and in turn teh OS relies heavily on the compiler to verify the safety of generated code. In addition there is load time type checking of registered handlers and guards to ensure expected behavior. Since handlers run in kernel space safety verification is important. While I believe that code generated by a trusted compiler can be in turn trusted by the system, it is not clear to me that a malicious compiler could not generate code to corrupt the system, or that a user in general could not generate code by means other than a trusted compiler to do the same. Perhaps this safety is inherantly checked within the compiles modules? The model of the OS is that of events and event handlers, where new handlers are the extentsions. Multiple handlers may be registered for a single event, and each handler may have a series of guards which determine for any event whether a corresponding handler should actually be invoked. Because handlers get fine grained access to low level system events, special purpose event handling can be implemented more efficiently than in traditional OSes. An example given is that of a video application which streams packets directly to a video framebuffer. A handler can move data directly from the the packet to the buffer, avoiding the multiple data copies and kernal calls usually present to move network data. Benchmarks suggest that these optimations are generally very effective ;)
The SPIN operating system is presented in this paper. Initially, after a small introduction on OS extensibility necessity, previous efforts to achieve extensibility are presented. Following, there is an introduction to the architecture of SPIN, and it's main feature is presented, it's protection model through which extensibility is achieved. SPIN uses the type-safety of the Modula-3 language to assert the safety of it's extension modules, and demands that every module is signed by the Modula-3 compiler, or asserted by external means. References are called "capabilities" and are actually simple pointers, which are asserted by the compiler to be safe, and therefore do not need futher protection. This increases efficiency. In addition, because of the language feature of Modula-3 to define specific interfaces between modules, SPIN implements a "naming" protection which is based on namespace-domains with specific interfaces to the outer world. The names that are used in every modules interface are checked (and type-checked) against everything that the module is linked with. Finally, every procedure defined in a module's interface is considered to be an "event handler", whereas every imported procedure is an "event", meaning that as long as it typechecks, there can be any combination of event-handlers and events, and it can change at run time. Based on that design, the main systems of SPIN are presented, namely memmory management, thread management and trusted access to physical resources. In the last section of the paper, system performance is measured against two other operating systems, OSF/1 and Mach. SPIN is found to be a more efficient operating systems in the applications considered because it allows for better OS extensibility. Overall, this is a well-written paper, that tries to present the big picture behind SPIN. Naturally, the presentation of a whole operating system cannot be completely covered in a paper, therefore, many details are missing. Moreover, the performance measurements section only uses two other operating systems, one of which shares a very large code base with SPIN, making it sound like only an improvement over OSF/1, even though the reader is promised in the introduction that the comparison includes "several other" operating systems.
This paper provides an overview of the SPIN operating system, focusing on its extensible architecture, and its speed. The central idea of SPIN is that all function calls are events, and all functions are event handlers. The whole system is designed for dynamic linking from the ground up, so it's able to outperform older systems. SPIN's extensibility is discussed in more detail in the second paper, but I like the idea that everything is extensible. Most programs wouldn't bother to manage their own VM or threads, but the statistics in the paper say that there's no cost incurred by the potential for extensions. Compared to recent papers we've read, SPIN's trusted computing base is large (the system core and the Mod-3 compiler). I assume that SPIN could be extended to use modules with proofs (so that the compiler wouldn't need to be trusted), but it seems like an acceptable risk to trust the core of the system. The statistics themselves were uninteresting. It's impressive how well SPIN outperforms OSF/1 and Mach, but it was designed with modern hardware and programming methods in mind, so it would be pretty disappointing if it was worse.
The paper is mainly about the Spin operating system and its architecture. It says that Spin provides an extension infrastructure, which enables the applications to specialize the operating system in order to achieve maximum performance or a particular level of performance. The paper claims the Spin operating system to be an extensible system and that it can dynamically specialized to meet the requirements of the applications. The paper underlines the four techniques that make Spin an extensible safe and a high performance operating system. The techniques are Co-location, Enforced Modularity, Logical protection domain and Dynamic call binding. The paper makes a very good point that these four techniques help in achieving extensibility but are not the only techniques that provide extensibility. Extensibility is finally obtained through system service interface. In the rest of the paper the authors have discussed several topics like need for extensible systems, the architecture of Spin, the services provided by Spin and finally the performance and evaluation of Spin. These topics have been dealt with in a very general way and I think that they can be applied to other extensible systems also. The paper does not describe the architecture of Spin in detail which I think it should have.
This paper describes the design of an operating system using two important programming technologies: safe languages and event-based programming. For the most part, it seems straightforward to develop an operating system in a type-safe language, and the benefits obtained are the same ones obtained in application programming. The event-based model has also been done for a while now (though this paper is rather old), but this paper offers an interesting optimization of it. Also, the way that they treat every procedure call as an event seems like it could be very powerful. What I find interesting about this paper is that it seems to provides a good solution to a problem that I have encountered: how to send high-bandwidth video data to the appropriate places in the computer while copying it as little as possible. Although I found that this problem was reasonably well handled by the design of UNIX, the approach given in this paper is more generally applicable.
The paper does a good job of hammering a couple of key points. The use of language features (in this case, Modula-3) to provide extensibility, safety, and performance is a key differentiator between SPIN and other related efforts. Using a language like Modula-3 allows SPIN to use direct procedure calls, boosting performance over related efforts. Also, only extensions have to be coded in Modula-3; regular applications can be coded in any language. Furthermore, the authors are not afraid to disclose that a certain level of "safety by assertion" is required in any system and some operations, such as Resolve, must violate semantics. Additionally, the SPIN extension model allows a programmer to avoid expensive operations that on conventional systems would repeatedly cross user/kernel boundaries. Last, SPIN's extensibility model draws its flexibility from an event-based design. A couple points are unclear, though. The authors compare SPIN to conventional operating systems. However, I believe these comparisons are invalid as SPIN is more of a meta-OS than a "real" operating system. Also, at times, such as when memory management and thread management are discussed, it is clear that the memory management and/or thread management scheme can differ between concurrently running applications. However, if a disk buffering/paging algorithm is changed, I don't see how such an algorithm could be applied only to one of many running applications. This leads me to believe that SPIN is well-suited only for special, single-purpose systems. Additionally, during the section on "Extensible thread management", the authors describe Mach's user-level C-Threads as anomalous; however, a couple paragraphs later, the SPIN thread framework is described and I believe the SPIN thread framework has a great probability for exhibiting anomalous behavior.
The SPIN operating system allows for run-time modification of an OS in a type-safe matter. The major motivator for such a design is that with the varying demands of different classes of applications, a general-purpose OS may not be optimized for all (or even any) of the classes - disk management requirements for a database may be completely orthogonal to a video server, for instance. Instead of writing separate operating systems for each target environment, separate extensions to the same OS may be applied for each set of performance requirements. Two features distinguish the SPIN OS. First, modularity is incorporated at the language level. Unlike shared-object kernel modules written in C, which popular OS flavors such as Solaris and Linux currently employ, SPIN requires type-soundness. This has two advantages: correctness and safety. Correctness of implementation is provided by requiring an extension to match a signature, thereby at least guaranteeing that the extension will be called correctly. Security is given by type-soundness - a pointer can only access objects of a compatible type, and not arbitrary memory. The second distinguishing feature of SPIN is its kernel-extension interface. Unlike conventional operating systems, which utilize RPC or traps, each extension "event" is either a single direct procedure call or a sequence of several indirect calls. This allows for decreased overhead relative to a conventional OS, as well as being able to eliminate a lot of unnecessary kernel-user translations.
Generated: Thu Mar 6 15:39:24 EST 2003 by mwh