This page provides a quick overview of the differences between the two versions of Fuchsia’s driver framework: DFv1 (legacy) and DFv2.
Key differences between DF1 and DFv2 are:
Device vs. node
In DFv1, we use the terms “device” and “device graph.” A device can be thought of as a piece of hardware. Drivers are bound to devices and operate on them. Drivers can also create child devices. In DFv1, when a driver binds to a device, it must create a child device. The device is then owned by the driver that created it.
In DFv2, we use the terms “node” and “node graph” (or "node topology”). A node can be thought of as something that exposes capabilities in a Fuchsia system. It could be a physical hardware device or a virtual representation of hardware. Drivers are bound to nodes and use their capabilities. Drivers can also create child nodes. The node is then owned by the driver that is bound to it.
libDDK vs. capabilities
In DFv1, drivers are not components. They do not have an incoming or outgoing
namespace to use capabilities in a Fuchsia system. Drivers communicate with the
driver framework using libDDK, which is a shared library
that exposes functions. Drivers create a messageable device if they want to be placed
in the /dev directory (a virtual file system). Then the driver framework will forward
FIDL messages back to the driver.
In DFv2, drivers are components. They have capabilities in their incoming
namespace. Some of these capabilities let them speak FIDL to the driver framework.
Drivers can use the DevfsExporter FIDL protocol to expose a channel to the
/dev directory. Using this channel, drivers and other components can speak FIDL
directly to each other.
Banjo vs. FIDL
In DFv1, drivers speak Banjo to each other. To get the Banjo protocol, a driver requests it from its bound device.
In DFv2, drivers speak FIDL to each other, like any other component in a Fuchsia system. A driver gets a FIDL channel from its incoming component namespace.