svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ieee80211_vap(9)
The 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 underlying
device. 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 inter‐
faces allow multiple vaps to be cloned. The virtual radio inter‐
face defined by the layer means that drivers must be structured
to follow specific rules. Drivers that support only a single in‐
terface at any time must still follow these rules. The virtual
radio architecture splits state between a single per-device
structure and one or more structures. Vaps are created with the
request. This results in a call into the driver's method where
the driver can decide if the request should be accepted. The vap
creation process is done in three steps. First the driver allo‐
cates the data structure with This data structure must have an
structure at the front but is usually extended with driver-pri‐
vate state. Next the vap is setup with a call to This request
initializes state but does not activate the interface. The dri‐
ver 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 re‐
quests from user applications. The driver can then reclaim re‐
sources held by the vap and re-enable device operation. The ex‐
act procedure for quiescing a device is unspecified but typically
it involves blocking interrupts and stopping transmit and receive
processing. Drivers are responsible for deciding if multiple
vaps can be created and how to manage them. Whether or not mul‐
tiple concurrent vaps can be supported depends on a device's ca‐
pabilities. For example, multiple hostap vaps can usually be
supported but many devices do not support assigning each vap a
unique BSSID. If a device supports hostap operation it can usu‐
ally support concurrent station mode vaps but possibly with limi‐
tations such as losing support for hardware beacon miss support.
Devices that are capable of hostap operation and can send and re‐
ceive 4-address frames should be able to support WDS vaps to‐
gether with an ap vap. But in contrast some devices cannot sup‐
port WDS vaps without at least one ap vap (this however can be
finessed by forcing the ap vap to not transmit beacon frames).
All devices should support the creation of any number of monitor
mode vaps concurrent with other vaps but it is the responsibility
of the driver to allow this. An important consequence of sup‐
porting multiple concurrent vaps is that a driver's method must
be written to handle being called for each vap. Where necessary,
drivers must track private state for all vaps and not just the
one whose state is being changed (e.g. for handling beacon timers
the driver may need to know if all vaps that beacon are stopped
before stopping the hardware timers).