class Callbacks

Called when the underlying device is released.

Called as part of the initialization of the device. The device is considered initialized

after txn.Reply() has been called with a ZX_OK status as parameter. The device can call

txn.Reply() at any time, either during the invocation of NetDevInit or at a later time from

the same thread or another thread. Call txn.Reply() with anything but ZX_OK will prevent the

device from being created.

Start the device's data path. The data path is considered started after txn.Reply() has been

called with a ZX_OK status as parameter. The device can call txn.Reply() at any time, either

during the invocation of NetDevStart or at a later time from the same thread or another

thread. To indicate that the data path has already started, call txn.Reply() with

ZX_ERR_ALREADY_BOUND, any other error code indicates a failure to start the data path.

Stop the device's data path. The data path will be considered stopped after txn.Reply() has

been called. The device can call txn.Reply() at any time, either during the invocation of

NetDevStop or at a later time from the same thread or another thread.

When the device receives this call it must return all TX and RX frames previously provided

and any further TX and RX frames received while in a stopped state must be immediately

returned. TX frames should be returned using NetworkDevice::CompleteTx with status

ZX_ERR_UNAVAILABLE and RX frames should be returned using NetworkDevice::CompleteRx with a

size of zero.

Get information from the device about the underlying device. This includes details such as RX

depth, TX depths, features supported any many others. See the device_impl_info_t struct for

more information.

Enqueue frames for transmission. A span of frames is provided which represent all the frames

to be sent. These frames point to the payload to be transmitted and will have any additional

headroom and tailspace specified in device_impl_info_t available. So in order to populate

headers for example the driver must first call GrowHead on a frame to place the data pointer

at the location where the header should be, then populate the header. Note that the lifetime

of the data pointed to by the span is limited to this method call. Once this method

implementation returns, the frame objects (but not the underlying data) will be lost. The

driver therefore needs to make a copy of these frame objects, for example by placing them in

a queue or submitting them to hardware before the method returns.

Enqueue available space to the device, for receiving data into. The device will provide any

number of buffers up to a total maximum specified during the NetDevGetInfo call for RX depth.

As the device completes RX buffers, thereby giving them back to NetworkDevice, the device

will gradually pass them back to the device through this call. The device is expected to

store all these space buffers and then use them to receive data. FrameStorage is intended for

such usage. As a convenience an array containing the virtual addresses where each VMO is

mapped is provided. The VMO id in the buffers can be used as a direct index into this array

to obtain the virtual address where the VMO has been mapped into memory. Note that in order

to get the address for a specific buffer the offset in the buffer needs to be added to the

VMO address. The number of addresses in this array matches the maximum number of possible

VMOs, defined by MAX_VMOS.

Inform the device that a new VMO is being used for data transfer. Each frame simply points to

a VMO provided through this call. Usually this VMO is shared among multiple frames and each

frame has an offset into the VMO indicating where its data is located. The device may need to

perform additional operations at the bus level to make sure that these VMOs are ready for

use with the bus, examples of this include making the VMO available for DMA operations. In

addition to providing the VMO the method call also provides a location in virtual memory

where the VMO has been memory mapped and the size of the mapping.

Inform the device that a VMO will no longer be used for data transfers. The device may have

to ensure that any underlying bus is made aware of this to complete the release. The vmo_id

is one of the IDs previously supplied in the prepare call. It is guaranteed that this will

not be called until the device has returned all TX and RX frames through CompleteTx and

CompleteRx. This means that the device does not need to attempt any cleanup and return of

frames as a result of this call.