Driver Framework Architecture Overview

In the ChorusOS operating system, a driver entity is a software abstraction of the physical bus or device. Creating a device driver using the Driver Framework allows the device or bus to be represented to, and managed in the ChorusOS operating system. The hierarchical structure of the driver software within the ChorusOS operating system mirrors the structure of the physical device/bus.

Each device or bus is represented by its own driver. A driver's component code is linked separately from the microkernel as a supervisor actor, with the device-specific code strongly localized in the corresponding device driver.

Note that a supervisor actor containing a driver code should be considered a container only rather than a real supervisor actor with its own execution personality. Driver code runs either in the interrupt execution environment (typically up-calls) or in the driver client execution environment (typically down-calls). In other words, the driver component code logically belongs to the current driver client (microkernel module or supervisor actor).

The driver is always considered a trusted system component.

This means that the Driver Framework defines a structure and principle. Since the driver is a trusted system component, care should be taken to ensure that drivers are written in conformance with the framework. Only the APIs that are authorized for drivers can be used (see API(5FEA)). Even if the task of creating drivers with the Driver Framework seems relatively simple. Some checking can be done when building in debug mode but this cannot replace writing the driver in compliance with the Driver Framework.

Driver components are organized, through a service-provider/user relationship, into hierarchical layers which mirror the hardware bus/device connections.

Interactions between these drivers are implemented via simple indirect function calls (down-calls and up-calls).

Figure 1-2 Bus/Device Hierarchy, in Hardware and Software