Skip to main content

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;
    fn suspend(
        &mut self,
        responder: Responder<Suspend, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn resume(
        &mut self,
        request: Request<Resume, ___T>,
        responder: Responder<Resume, ___T>,
    ) -> 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.

Source

fn suspend( &mut self, responder: Responder<Suspend, ___T>, ) -> impl Future<Output = ()> + Send

Returns when the driver has suspended the hardware. This is called when the power element requests the off power state. The driver should turn off the hardware as a response to this call.

Note on execution order after a suspend is requested by the power element:

  • dispatchers stop accepting new work in the work queue
  • dispatcher drains previously queued work
  • Once all work is drained, this method is called

The driver will not immediately |Stop| after it has been suspended. It will first go through |Resume| before it is told to |Stop|.

Source

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

Returns when the driver has resumed the hardware. This is called when the power framework requests the power element move to the on power state. The driver should turn the hardware back on as a response to this call.

|power_element_lease| is the lease associated with the current wake if the wake was from a wake vector. Otherwise it is None.

Note on execution order after a resume is requested by the power element:

  • This method is called (the dispatcher does not accept any other work at this point)
  • Once this method completes, dispatchers start accepting new work in the work queue

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§