next up previous
Next: 2 Variables in CLANGER Up: CLANGER : an interpreted Previous: CLANGER : an interpreted

1 Background

Nemesis is the operating system being developed as part of the Pegasus ESPRIT Project [3]. It is based on a paradigm for resource management which locates as much operating system functionality as possible in the application, thereby reducing crosstalk between application domains.

This is achieved using a structure and linkage mechanism based on the notion of interfaces, described in [8]. An interface is the point at which a service is offered. It is implemented as a closure, i.e.  a pair of pointers: one to a state record opaque to the client, and one to an array of function pointers called a method suite. The number and signatures of the functions in the method suite make up the type of the interface, and interface types are defined in an called MIDDL. Invocation between protection domains and between address spaces is performed through surrogate interfaces.

Interfaces are the basic linkage mechanism in Nemesis. The operating system code is composed of a set of modules, whose only externally visible symbols are a small number of closure addresses. To give an idea of the size of modules (and thus the granularity of linkage units), the system as it stands for Digital Alpha/AXP machines comprises about 25 modules, with sizes ranging from about 100 to 2,500 lines of C source. Most modules are about 300-400 lines long.

At a level above virtual addresses, all computational objects in Nemesis can be named in a way modelled on [9]. An interface of type Context provides a flat name space in which textual strings can be bound to objects of arbitrary types. Naming graphs can be built by binding names in one Context to other Contexts. Name spaces can also be composed in an ordered way in the manner of Plan 9's ``union directories'' [7]. Interfaces conforming to type Context are used extensively within Nemesis.

Nemesis also provides a module called TypeSystem. This component of the system encapsulates data structures representing every interface type known to the system together with all operation signatures and concrete types defined within each interface. The information is presented as a collection of interfaces. The Type System is analogous to the Cedar Abstract Machine [10] or the CORBA Interface Repository [4]. In addition, the Type System provides a tagged Any type plus associated runtime type checking and narrowing. It is this Any type to which textual names are mapped by Context interfaces.

These two facilties make CLANGER possible: ubiquitous typing within the operating system (coupled with a means to interrogate the type system at runtime), and a uniform naming model based on pathnames, flat name spaces and runtime typing. Given an object and its type, an instance of the interpreter can perform any legal operation on it in a typesafe manner without any prior knowledge of its structure. Any linkage-level interface in the operating system can potentially be manipulated from the command line. CLANGER can perform any non-time-critical operation that a piece of C code can.


next up previous
Next: 2 Variables in CLANGER Up: CLANGER : an interpreted Previous: CLANGER : an interpreted

T. Roscoe