[RFC] WPA Supplicant plugins

[Sane, Jayant]

We have been thinking about extending the supplicant to support additional L2 protocol modules w/o they being tightly integrated within the supplicant. This could improve long term maintainability of the supplicant and affords some freedom to such protocol developers.  Likewise we thought of introducing a concept of binary loadable library like plugins implementing such protocols and providing with appropriate interfaces to allow enabling the protocol plugs.  

Problem statement:
- Functional extensions need to be coded in the supplicant.
	* Pollutes supplicant, cannot upstream, requiring constant rebasing with upstream
- Segregation of custom functionality xlates into RPC hop based separation
	* Performance or platform/environment constraints can make it infeasible
- Lack of proper published API leads to inconsistency across various interfaces
- RPC interfacing code intertwined with core

Plugin Proposal:
- Cleanly segregated from supplicant while being in-process
	* Plugs can be compiled independently
- Load decision can be run-time* (can also be statically linked)
- Minimal changes to supplicant
- Creates a formal, public supplicant API
	* Promotes consistency and allows for conscious extensibility
	* Shields supplicant and plugins from internal changes on either sides.

Scope and Design: 
- Presently confined to control plane functionality (upper edge).
- Plugins are shared libraries exposing some std interface to allow loading, init/de-init by supplicant
- Supplicant supports explicit subscription based event model
- Plugins access supplicant functionality using published Supplicant APIs

Plugin design:
- Plugins define and expose a 'plugin' structure that contains plugin's version* and pointers to entry point methods for
	* Initialization: invoked during supplicant init
	* Un-initialization: invoked before supplicant shutdown
	* Interface added: invoked when supplicant starts managing a new interface.
	* Interface removed: invoked when an interface is removed in supplicant.
  (version mismatches only generate warning log message)
- Supplicant hands out a global handle and an API v-table when invoking plugin's initialization method.
	* Allows transparent interception (if needed for certain applications). 
- Supplicant hands out an interface-plugin specific handle during interface added callback.
- Plugins can add/remove interfaces along with invoking interface specific functionality (scan, etc).
- Plugins are expected to register for any events of interest by supplying an event callback method.
- Supplicant invokes each of the registered callback for a given event.
- Plugins invoke supplicant APIs using actual supplicant handles (global or interface specific).
	* No changes to existing supplicant implementation
	* The handles are still opaque to plugins
	* certain existing types are part of the Supplicant API/interface.
- Plugins have ability to store and retrieve interface specific private data.

Status:
- Necessary changes for plugin support are completed and unit tested
	* Aligned with recent versions of upstream code.
- D-Bus module, with old and new interfaces, has been converted into a 'static' plugin. This was chosen to demonstrate the concept with something that is being used in real life.
- WIP on an Intel internal plugin
- API Design: Uses accessor methods for access to fields of opaque types (e.g. struct wpa_supplicant) from among other choices and was not the preferred choice. The API footprint is large due to get_* type methods. Pl refer to README, available at the link below, for some more info on it

Patches: 
Available at http://intellinuxwireless.org/supplicant_plugin_patches/ 

rgds, 
Jayant