3 Introduction to OSKit Interfaces

The OSKit's interfaces provide clean, well-defined intra-process or intra-kernel protocols that can be used to define the interaction between different modules of an operating system. For example, the OSKit provides a ``block I/O'' interface for communication between file systems and disk device drivers, a ``network I/O'' interface for communication between network device drivers and protocol stacks, and a file system interface similar to the ``VFS'' interface in BSD. However, the OSKit's interfaces were designed with a number of properties that make them much more useful as parts of a toolkit than are comparable traditional OS-level interfaces. These properties partly stem from the use of the Component Object Model (COM), described in Chapter 4 as the underlying framework in which the interfaces are defined, and partly just from careful interface design with these properties in mind. The primary important properties of the OSKit interfaces include:

• Extensibility. Anyone can define new interfaces or extend existing ones with no need to interact with a centralized authority. Components can simultaneously use and export interfaces defined by many different sources.
• Simplicity. All of the OSKit's interfaces take a minimalist design strategy: only the most obvious and fundamental features are included in the base interfaces. Get it right first; frills and optimizations can be added later through additional or extended interfaces.
• Full extensibility while retaining interoperability. Adding support in a component for a new or extended interface does not cause existing clients to break. Similarly, adding support in a client for a new interface does not make the client cease to work with existing components.
• Clean separation between components. The clean object model used by the OSKit interfaces ensures that components do not develop implicit dependencies on each other's internal state or implementation. Such dependencies can still be introduced explicitly when desirable for performance reasons, by defining additional specialized interfaces, but the object model helps prevent them from developing accidentally.
• Orthogonality of interfaces. Like the OSKit components that use them, the interfaces themselves are designed to be as independent of and orthogonal to each other as possible, so that exactly the set of interfaces needed in a particular situation can be used without requiring a lot of other loosely related interfaces to be implemented or used as well.
• No required standardized infrastructure code. The OSKit interfaces can be used irrespective of which actual OSKit components are used, if any; they do not require any fixed ``support libraries'' of any kind which all clients must link with in order to use the interfaces. This is one important difference between the application of COM in the OSKit versus its original Win32 environment, which requires all components to link with a standard ``COM Library.''
• Efficiency. The basic cost of invocation of an OSKit COM interface is no more than the cost of a virtual function call in C++. Through the use of additional specialized interfaces even this cost can be eliminated in performance-critical situations.
• Automation. The simplicity and consistent design conventions used by the OSKit's interfaces make them amenable to use with automated tools, such as Flick, the Flux IDL Compiler, in the future.
• Binary compatibility. The Component Object Model and the OSKit's interfaces are designed to support not only source-level but binary-level compatibility across future generations of components and clients.

As with all other parts of the OSKit, the client is not required to use the OSKit's interfaces as the primary inter-module interfaces within the system being designed. Similarly, the client may use only some of the interfaces and not others, or may use the OSKit's interfaces as a base from which to build more powerful, efficient interfaces specialized to the needs of the system being developed. Naturally, since the specific components provided in the OSKit must have some interface, they have been designed to use the standardized OSKit interfaces so that they can easily be used together when desired; however, the OS developer can choose whether to adopt these interfaces as primary inter-module interfaces in the system, or simply to use them to connect to particular OSKit components that the developer would like to use.

• 3.1 Header File Conventions
  • 3.1.1 Basic Structure
  • 3.1.2 Namespace Cleanliness
• 3.2 Common Header Files
  • 3.2.1 boolean.h: boolean type definitions
  • 3.2.2 compiler.h: compiler-specific macro definitions
  • 3.2.3 config.h: OSKit configuration-specific definitions
  • 3.2.4 machine/types.h: basic machine-dependent types
  • 3.2.5 types.h: basic machine-independent types