P2P UI/next steps

• wpa_supplicant deemed complete, no integration of things like directly communicating with avahi etc. since it may or may not be suitable for the system
• necessary to have new p2p management component
• p2p mgmt component would offer public API and consume wpa_supplicant's (dbus) APIs

P2P needed functionality

• better virtual interface support
• advertise "feature matrix", virtual interface combinations
• beacon interval restrictions
• power saving
• need normal powersaving in place first

multi-channel operation

• part of feature advertisement matrix
• implement r-o-c per interface, OK to remove per-wiphy version of it
• need mac80211 design for multiple chans, backward compat with single-channel devices
• r-o-c offload to hardware

regdb patch requirements

• basically the processes we talked about earlier
• use wireless-regdb mailing list

world roaming

• mostly userspace problem
• kernel - enable overwriting regdom from world roaming?
• mostly an issue of trust

backporting

• remove pcmcia to remove issues
• maybe look at more ifdefs
• maybe make some patches for older kernels optional

automated testing

• presentation by Sam/Paul
• they'd like
  • HT radiotap (Johannes to post RFA)
  • ? (ISTR there was something else)

legacy drivers / documentation / open firmware

...

maintenance issues / community relations

...

private/specialised APIs

• example: microAP (Marvell), but this should have proper API once the code requiring it goes into mainline; Johannes noted that often enough not doing this leads to APIs that, while somewhat generic, don't quite port to other drivers.

• example: BT coex – currently sysfs (Nokia); discussion: could add APIs that are part of mainline, defined in nl80211, but not as generic as the regular APIs, defined in a specialised namespace. Do not want to add back dynamic registration of commands, as that would enable out of tree drivers to come up with crap. John noted that some things may simply require out of tree patches for specialised devices/platforms, and that sysfs files, while ugly, solve the problem "well enough".

powersaving

...

IBSS

• IBSS not really liked by anyone much
• however, still required
• desire for complete IBSS (including RSN) to avoid having to support WPA-None hacks
• per-STA GTK also useful for fast transition (FT, 802.11r)

• GTK patch needs APIs to allow driver to remove key from hw crypto if needed (e.g. when GTKs for multiple STAs are present) – this is needed for TX with keys if they must be removed from hw (rather than just disabled for RX)

tracing

• Johannes gave short demo of iwlwifi tracing
• short discussion on adding more tracepoints, seems good