New driver API for Wireless Extensions
		--------------------------------------

Intro :
-----
	Over time, I've observed what's good and what's wrong with the
Wireless Extensions. After listening to complaints and comments from
various wireless driver developpers (me included), I've decided it's
time for a new driver API for Wireless Extensions.

Executive summary :
-----------------
	In the old driver API, all Wireless Extensions were processed
in the driver ioctl handler.
	With the new API, the driver defines a bunch of handler, each
associated with a specific Wireless Extension, and a kernel wrapper
make sure to call the appropriate handler with the appropriate
parameters.

Main advantages :
---------------
	o backward compatible with old API, both API can be mixed
	o easy migration from old API to new API (data structures unchanged)
	o break huge ioctl function in driver in small handlers
	o various parameters checks before calling the driver
	o handle all user-space <-> kernel-space data copy
	o remove all ioctl assumptions in the driver

Drawback :
--------
	o bloat (especially kernel)
	o need to migrate existing drivers to new API

Comments :
--------
	A lot of repetitive code has moved from the driver to the
kernel (like parameter checks and user/kernel space copy). This means
that the bugs are grouped into one place instead of scattered all over
the drivers, and also that things are simpler for people writting
drivers.
	The removal of ioctl assumptions from the driver (mostly the
removal of user/kernel space copy) mean that we are now free to change
the user space API and that we can call this code from the kernel. In
particular, it should be now trivial plug APIs like netlink or devfs
on top of the driver API.
	The bloat is a concern. The rest of the document look at this
in some details. Note that those numbers are for my configuration and
just serve as an estimate.
	I don't mention performance. Performance is not critical for
this API. However, I believe the new API is marginally faster (you are
free to prove me wrong).
	If you want more details, I'm afraid you will have to look in
the code.

Kernel bloat :
------------
	Size of the core networking object (without the protocols) as
found in linux/net/core :
		core.o after :		100133 bytes
		core.o before:		 97008 bytes
		bloat :			  3125 bytes -> +3%
	Of course, Wireless Extension is optional, and if you disable
the CONFIG_NET_RADIO and CONFIG_NET_PCMCIA_RADIO options, you don't
compile any of the stuff :
		core.o no-wireless :	 96803 bytes
	So, the Wireless Extensions overhead went from 205 bytes to
3330 bytes (0.2% to 3%).
	Note : the whole networking stack in my case is 603714 bytes,
and my vmlinux over 2 Mbytes, so for most kernels this bloat will be
lost in the noise...

Old Wavelan driver :
------------------
	I've chosen the old Wavelan driver because the old API
implementation has been really optimised in this driver and it uses
mostly simple extensions.
		wavelan.o after :	24900 bytes
		wavelan.o before :	24856 bytes
		bloat :			   44 bytes -> +0.2%
	Well, I'm disapointed. I guess I could squeeze more with the
new API by putting psa_checksum in a commit handler.

Orinoco driver :
--------------
	The Orinoco driver is representative of a modern 802.11 driver
and support a wide range of Wireless Extensions.
		orinoco.o after :	42420 bytes
		orinoco.o before :	47180 bytes
		bloat :			-4760 bytes -> -10%
	That's good news. The saving is mostly the removal of
copy_to/from_user and the removal of the big switch.

Conclusion :
----------
	Bloat is only a minor issue, and overall I beleive the new API
is worth the pain of upgrading.
	Note that the old API is *not* going away (at least, not
soon), so old drivers are forward compatible and driver maintainers
can take their time to migrate (i.e. : never).

	Jean II