Domain/OS solves this problem by its adherence to object-oriented structuring techniques. Each object in the file system is marked with a unique type identifier (type UID). I/O on each object type is han-dled by a different manager. When an object that is not one of the built-in types is opened, the device-independent 110 subsystem (the switch) locates the manager for that type, and dynamically loads it. It then calls a manager initialization routine which exports a vector of procedures implementing operations like open, close, read, write, and seek.
If a manager supports other semantics, say those of a tty, it may export other sets of operations, such as those for setting erase and kill characters or for setting raw and cooked modes. Subsequently, all operations on the new file descriptor will be switched through to
the manager's exported procedures.
Apollo documents the interfaces expected by the switch and guar-antees that they'll remain the same from one software release to the next. These published interfaces and the tools for defining new types are known as the Open System Toolkit. Open System Toolkit
2-16 Domain/OS Design Principles
managers run in user space, and therefore have all the above-de-scribed facilities available to them for shared memory and synchro-nization.
Developers can use the Open System Toolkit to add interesting new file types to the system, while applications that use these new types continue to work without change. A simple example might be a circular log file type. Another useful type might be one which main-tains all the versions of a text file under source version control.
When an application opened a text file under version control, it would read the most recent version of the text. This obviates the need to perform a separate "fetch" operation before an application can look at a source module. The GPIO system can also combine with the Open System Toolkit to give standard access to new de-vices.
Objects
An object is a container, and each object has a unique identifier called a xoid associated with it. The operating system does not care what the contents of an object are. Objects that the system manipu-lates can "contain" such diverse things as ASCII files, printers, and tape drives.
Applications programs generally want to perform certain kinds of functions on objects, like reading, writing, creating, and deleting.
Traditionally, in the case of peripherals, an operating systems pro-grammer would write a device driver for a new class of device that the system would support, add the driver to the operating system source code, and then rebuild the system software.
In Domain/OS, subroutine libraries supplied with the operating sys-tem perform basic operations like reading and writing on their asso-ciated type of object. These subroutine libraries are called type managers. Each type manager supports certain traits. A trait is an ordered set of the operations that canbe performed on an object.
Users can add new types of objects and their associated managers with the Open System Toolkit. Rather than having to rebuild and reboot the operating system, the user can install a new type man-ager with a single shell command.
Domain/OS Design Principles 2-17
Type managers can implement standard operations like read and write in any way appropriate. New system functionality can be added without disturbing system operation. Thus, the new function-ality is immediately available to all programs. for physical resources like disks, network controllers, and memory, as well as for abstract concepts like files, processes, and address spaces.
Since an object is only a container, each type of object on the sys-tem looks the same to an applications program. Because of this, the application can contain, say, a read call that is compiled into the program. At execution time, the user can redirect the program and the call to operate on any kind of object. For example, if a program attempts to open an object of the ASCII file type, the ASCII file type manager performs the appropriate functions. Thus, developers can create a group of general-purpose utilities that operate on all object types instead of creating and maintaining programs for each individual type on the system.
Much of this is true of traditional UNIX implementations, but few let you easily add new types to the system. As a result, in most UNIX implementations, users cannot be sure that a new type added at one release level of the operating system will still operate" cor-rectly with a new release. Under Domain/OS, new types will work correctly with later operating system releases.
A trait represents a certain behavior that an object supports. Each trait is an ordered set of operations. An object supports a trait if the object's type. manager implements the operations that define the trait. For every trait that a type manager supports, the manager provides a list of pointer& to procedures that implement the opera-tions in the trait. For further details on the trait/type system, see the paper An Extensible I/O System in Part 2 of this book.
2-18 Domain/OS Design Principles
How Type Managers Are Loaded
When an applications program written using the Open System Toolkit attempts an operation on a pathname, the system resolves the name of the object into a xoid and then ascertains the object type that the xoid identifies. If the manager for that type is not currently loaded. the system loads it from the trait/type database (which tracks which type managers are currently loaded). into the address space of the process that requested the object.
A type manager is loaded only when a process demands it. Unlike a device driver. the manager does not need to be bound into the operating system in advance. Thus. a type manager doesn't con-sume system resources until it actually is loaded.