en:developers:documentation:nl80211
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
en:developers:documentation:nl80211 [2015/01/26 09:49] 127.0.0.1 external edit |
en:developers:documentation:nl80211 [2024/02/27 19:24] (current) Johannes Berg add wifi prefix to subject |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| * [[en/users/Documentation/hostapd|hostapd]] | * [[en/users/Documentation/hostapd|hostapd]] | ||
| * [[en/users/Documentation/wpa_supplicant|wpa_supplicant]] (with **-Dnl80211**) | * [[en/users/Documentation/wpa_supplicant|wpa_supplicant]] (with **-Dnl80211**) | ||
| + | * [[https://iwd.wiki.kernel.org/|iwd]] | ||
| + | * [[en/users/Documentation/NetworkManager|NetworkManager]] (scanning etc.) | ||
| ===== libnl tiny ===== | ===== libnl tiny ===== | ||
| Line 20: | Line 21: | ||
| [[http://openwrt.org/|OpenWrt]] folks created a tiny version of libnl based on a git snapshot, which only contains genl, not rtnetlink or any of the netfilter stuff, and compiles down to less than 30k in binary size. You can find it here: | [[http://openwrt.org/|OpenWrt]] folks created a tiny version of libnl based on a git snapshot, which only contains genl, not rtnetlink or any of the netfilter stuff, and compiles down to less than 30k in binary size. You can find it here: | ||
| - | [[https://dev.openwrt.org/browser/trunk/package/libs/libnl-tiny|https://dev.openwrt.org/browser/trunk/package/libs/libnl-tiny]] | + | [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=package/libs/libnl-tiny;hb=HEAD]] |
| - | svn co svn://svn.openwrt.org/openwrt/trunk/package/libs/libnl-tiny | ||
| Line 43: | Line 43: | ||
| Current users of the testmode interface are: | Current users of the testmode interface are: | ||
| - | * [[en/users/Drivers/wl12xx/calibrator|wl12xx calibrator]] (chipsets WL1271 etc.) | + | * [[http://linuxwireless.sipsolutions.net/en/users/Drivers/wl12xx/calibrator/|wl12xx calibrator]] (chipsets WL1271 etc.) |
| TODO: could list (references to) ready-made scripts which implement nicely automated / elegant workflows for SAR testing etc. | TODO: could list (references to) ready-made scripts which implement nicely automated / elegant workflows for SAR testing etc. | ||
| For ATH9K chipsets, there's SAR testing functionality provided via the non-testmode setting [[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath9k/Kconfig|CONFIG_ATH9K_TX99]]. Hmm, this possibly needs conversion to (additionally?) providing the generic nl80211 testmode functionality? | For ATH9K chipsets, there's SAR testing functionality provided via the non-testmode setting [[http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/ath9k/Kconfig|CONFIG_ATH9K_TX99]]. Hmm, this possibly needs conversion to (additionally?) providing the generic nl80211 testmode functionality? | ||
| + | |||
| + | ===== vendor-specific API ===== | ||
| + | |||
| + | Under the NL80211_CMD_VENDOR command, there's the ability to register vendor-specific behavior. For a long time, we've explicitly rejected these upstream, but after many discussions some may be allowed, subject to (at least) the following constraints: | ||
| + | |||
| + | - Upstream vendor commands shall not replace existing functionality. | ||
| + | - The submitter shall consider a pure nl80211 implementation and explain the reasoning against it in the commit message. | ||
| + | - Example users/use cases of the API shall be documented. | ||
| + | - The newly proposed API shall be subject to stable API rules. | ||
| + | - Unless the data inside NL80211_ATTR_VENDOR_DATA is just an opaque blob not used by the driver (but e.g. by firmware), sub-attributes shall be used inside of it, and those shall be documented. | ||
| + | - Vendor command and sub-attribute definitions shall be in a common header file location (TBD, e.g. include/uapi/nl80211-vnd-*.h) | ||
| + | - Patches introducing such commands shall be submitted separately, not "buried" in big driver patchsets. Give them a "wifi: nl80211: vendor-cmd: " prefix to make them easily identifiable. | ||
| + | |||
| + | The goal with these rules is to enable use of vendor commands in a fashion that is transparent enough to allow later reuse by other components with similar needs, and then potentially defining "real" nl80211 API for the use case in question. | ||
en/developers/documentation/nl80211.1422265793.txt.gz · Last modified: 2016/09/19 06:28 (external edit)
Page Tools
