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 as a container only rather than as 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, but since the driver is a trusted system component, parameter and logic checking are not performed on most drivers in release mode. Even if the task of creating drivers with the Driver Framework seems relatively simple, care should be taken to ensure that drivers are written in conformance with the framework. Some checking can be added in debug mode, but this can not replace writing the driver in compliance with the Driver Framework.

Driver components are organized, through a services-provider/user relationship, into hierarchical layers which mirror the hardware buses/devices connections.

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

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

To sum up, the ChorusOS operating system Driver Framework can be considered in two ways:

• A hierarchical set of APIs which defines the services provided for and used by each bus or device driver at each layer of the architecture. This approach ensures portability and functionality across various platforms and continued validity of drivers across subsequent system releases.

• A set of mechanisms implemented by the ChorusOS microkernel, ensuring compliance and synchronicity with the ChorusOS operating system architecture and methods.

Figure 1-2 shows the objects involved in the ChorusOS Driver Framework:

Figure 1-2 Driver Framework Objects