Skip to content

Latest commit

 

History

History
40 lines (32 loc) · 1.45 KB

File metadata and controls

40 lines (32 loc) · 1.45 KB

Using LLCPP over the driver transport

When a protocol has a @transport("Driver") attribute, the protocol is defined to use the driver transport:

library example;

@transport("Driver")
protocol Protocol {
    TwoWay(struct {
        request uint32;
    }) -> (struct {
        response uint32;
    });
};

The driver transport builds on building blocks from the Fuchsia driver runtime, which comes with different memory management requirements and threading model than Zircon channels. As such, the FIDL client and server types are different from those found in protocols over Zircon channels, to provide a tailored API.

As a general rule, most client/server types under the fidl:: namespace will have a counterpart in the fdf:: namespace, that provides the same features but is specialized to the driver runtime. For example, whereas one would write fidl::WireClient to declare an asynchronous client over the Zircon channel transport, to use the example protocol above one would write fdf::WireClient<example::Protocol>. The generated FIDL header is of the form #include <fidl/example/cpp/driver/wire.h>.

LLCPP over the driver transport is under iteration. For now the tests may serve as examples of using the bindings.