In Fuchsia, all communication occurs over FIDL calls, for both drivers and non-drivers. What differs is how drivers' services are discovered and how connection is established.
For driver-to-driver communication, Fuchsia uses the
node topology to place parent nodes' capabilities in a child
node's incoming FIDL namespace (that is, under
/svc as directories and files).
This setup enables a driver (once bound to the child node) to access FIDL
services inherited from the parent nodes.
However, communication from a non-driver component to a driver takes place in two phases:
For non-driver components, the first task is to discover which drivers' services
are available in the system. These services are provided by the drivers that are
currently bound to nodes representing hardware or virtual devices in the system.
A filesystem known as
devfs provides a mechanism for discovering these services.
The following events take place for non-driver to driver communication:
- To discover driver services in the system, a non-driver component scans the
directories and files in
- The non-driver component finds a file in
devfsthat represents a service provided by the target driver.
- The non-driver component opens this file and contacts the target driver.
- After the initial contact, a FIDL connection is established between the non-driver component and the driver.
- From this point, all communication takes place over the FIDL channels.
Service discovery (using devfs)
The driver manager hosts a virtual filesystem named
(as in "device filesystem"). This virtual filesystem provides uniform access to
all driver services in a Fuchsia system to Fuchsia’s user-space services
(that is, components external to the drivers). These non-driver components
establish initial contacts with drivers by discovering the services of the
target drivers in
devfs is a directory capability exposed by the driver
manager. Therefore, by convention, components that wish to access drivers mount
devfs under the
/dev directory in their namespace (although it’s not
devfs to be always mounted under
devfs hosts virtual files that enable Fuchsia components to route messages to
the interfaces implemented by the drivers running in a Fuchsia system.
In other words, when a client (that is, a non-driver component) opens a file
/dev directory, it receives a channel that can be used to make
FIDL calls directly to the driver mapped to the file. For example,
a Fuchsia component can connect to an input device by opening and writing to
a file that looks like
/dev/class/input-report/000. In this case,
the client may receive a channel that speaks the
Drivers can use the
fuchsia.device.fs protocol to export
devfs. The path under the
/dev directory for a driver is the
direct reflection of the path in the node topology. Therefore, if a driver wants
to show up in the right place in
devfs, it needs to make sure that its
topological path and protocol correspond correctly.
Once an initial contact is made between non-driver and driver components
devfs, the components can exchange FIDL handles. From this point,
these components make use of FIDL calls for communication, just like any
other components in Fuchsia.
Drivers, as Fuchsia components, have an incoming FIDL namespace
filled with capabilities the drivers can use. Some of these capabilities may be
inherited from their parent driver (for example, a PCI device will have
fuchsia.hardware.PCI capability from its parent node). Drivers can use
these capabilities to make FIDL calls to their parent drivers. Similarly,
their clients (that is, non-driver components) can also use the capabilities
received from the drivers to make FIDL calls to the drivers.
These FIDL calls, by default, get routed through the Zircon kernel. However, if the target driver is in the same process (therefore, in the same driver host), the driver runtime can route the FIDL calls to remain in process, without going in and out of the Zircon kernel.