Important: This page contains information that is specific to the new version of the driver framework (DFv2).
To provide services for devices in a Fuchsia system, drivers must be bound to nodes that represent the devices. The driver manager maintains the topology of nodes, where each node represents access to a hardware or virtual device in the system. When a driver is matched to a node, the driver can bind to the node. Once bound to the node, the driver can start providing services for the device that the node represents. For example, a USB keyboard driver may bind to a node representing a keyboard device.
To identify which drivers can bind to which nodes, each driver has bind rules and each node has a set of binding properties. A driver’s bind rules describe the qualification of a node that the driver can serve effectively. When the driver framework attempts to match a driver to a node, each unbound node’s binding properties are compared to the driver’s bind rules. If a node’s binding properties satisfy the driver’s bind rules, the driver framework allows the driver to bind to the node.
When a Fuchsia system boots up, the driver manager tries to construct a node topology that represents all the hardware and virtual devices in the system, and the driver index enumerates all the drivers known to the system.
The following events take place during the initial booting of a Fuchsia system:
After the initial run of scanning and binding, whenever a new driver appears (for instance, a new driver is loaded to the system), the driver manager sends all unbound nodes in the topology to the driver index to be matched against the new driver. When a node is matched, the driver manager binds this new driver to the node, an instance of the driver is placed in a driver host, and the driver host starts serving the device’s capabilities to other Fuchsia components in the system.
For more details on bind rules, see Driver binding, which was written previously for the driver framework version 1 (DFv1).
While drivers are often bound to devices, some drivers are bound to boards (such as PCI and ACPI) that may have multiple devices connected to them, both statically and dynamically.
Upon the initial binding to a node, a board driver (such as acpi
) parses a binary blob passed from the system (which can be ACPI bytecode or a compiled device tree) and informs the driver manager of the static set of devices connected on the board. These devices get bound to drivers through the normal binding process orchestrated by the driver index. From this point, these drivers (that are bound to the child nodes of the board driver) dynamically query the hardware for additional information. From this information, the drivers may discover new devices to be added to the topology. This process occurs recursively as more devices are discovered and introduced to the topology.