software layer provides a support framework for drivers that includes
a virtual radio API that is exported to
users through network interfaces (aka vaps) that are cloned from the
These interfaces have an operating mode
(station, adhoc, hostap, wds, monitor, etc.)
that is fixed for the lifetime of the interface.
Devices that can support multiple concurrent interfaces allow
multiple vaps to be cloned.
The virtual radio interface defined by the
layer means that drivers must be structured to follow specific rules.
Drivers that support only a single interface at any time must still
follow these rules.
The virtual radio architecture splits state between a single per-device
structure and one or more
Vaps are created with the
This results in a call into the drivers
method where the driver can decide if the request should be accepted.
The vap creation process is done in three steps.
First the driver allocates the data structure with
This data structure must have an
structure at the front but is usually extended with driver-private state.
Next the vap is setup with a call to
This request initializes
state but does not activate the interface.
The driver can then override methods setup by
and setup driver resources before finally calling
to complete the process.
Both these calls must be done without holding any driver locks as
work may require the process block/sleep.
A vap is deleted when an
ioctl request is made or when the device detaches (causing all
associated vaps to automatically be deleted).
Delete requests cause the
method to be called.
Drivers must quiesce the device before calling
to deactivate the vap and isolate it from activities such as requests
from user applications.
The driver can then reclaim resources held by the vap and re-enable
The exact procedure for quiescing a device is unspecified but typically
it involves blocking interrupts and stopping transmit and receive