Hmm.  Actually, I think it would be better if all the management functions
with state transition in 802.11 are implemented in daemon rather than kernel.
But I feel it is difficult for us to define generic API for 802.11 based
driver because of various firmware.  So I'm not sure for us to be able to
define APIs firmly enough for our compabitility commitment.

Though I still want to reuse bpf for the purpose, if we could hide these
new APIs for the Host AP Daemon from other applications, i.e. if we can
reserve ability for future break compatibility of these APIs, I'd agree
to your proposal.

Perhaps at least we need version in the message from/to kernel, and may be
just use IEEE80211_FC0_SUBTYPE_XXX instead of redefine subset of the
message to be handled for hostapd for future work which moves some
functionality of STA into some userspace daemon.

Atsushi Onoe