DriverServerHandler

fidl_next_fuchsia_driver_framework

Trait DriverServerHandler 

Source 
pub trait DriverServerHandler<___T: Transport = DriverChannel> {
    // Required methods
    fn start(
        &mut self,
        request: Request<Start, ___T>,
        responder: Responder<Start, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn stop(&mut self) -> impl Future<Output = ()> + Send;

    // Provided method
    fn on_unknown_interaction(
        &mut self,
        ordinal: u64,
    ) -> impl Future<Output = ()> + Send { ... }
}
Expand description

A server handler for the Driver protocol.

See Driver for more details.

Required Methods§

Source

fn start( &mut self, request: Request<Start, ___T>, responder: Responder<Start, ___T>, ) -> impl Future<Output = ()> + Send

Starts the driver with the given |start_args|.

Drivers should finish their initial setup and enumeration before returning from |Start|. In particular they should enumerate all currently available nodes by utilizing fuchsia.driver.framework/Node.AddChild and waiting for all calls to be completed.

The Framework will not consider the driver to be started until this call has returned successfully. Therefore a driver will not have |Stop| called on it until after it has replied to |Start| successfully.

If a driver returns an error, it will not have |Stop| called on it before the Driver Framework initiates shutdown of the driver’s dispatchers. Therefore it should have performed all necessary cleanup before returning an error.

Source

fn stop(&mut self) -> impl Future<Output = ()> + Send

Stops the driver. To stop, the driver should teardown any resources it set up in or after |Start|. This is a one-way FIDL method. When the driver has completed stopping, it should close its server end. Asynchronous operations should fully complete before closing the server end.

Provided Methods§

Source

fn on_unknown_interaction( &mut self, ordinal: u64, ) -> impl Future<Output = ()> + Send

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors§