Re: [RFC] Wireless extensions rethink

[Jeff Garzik <jgarzik@pobox.com>]

Jean Tourrilhes wrote:
> 	I think you did not understood my idea at all.
> 	If you build a set of generic wrappers and hook them in the
> iw_handler table, you could trivially add the features you feel are
> missing into those wrappers. Those wrappers would expose whatever API
> you choose to the driver, call your struct wireless_ops for example.

That doesn't help anything.  Wrappers add code, while not solving the 
following problems...

You want to expose a _specific_, fine-grained API to the driver.  That 
is by definition the smallest interface one can design for the low-level 
driver.  Anything else requires "additional work" -- from simple 
type-casting to real code.

The three major problems of the current WE iw_handler interface 
specifically are,

1) uses array, rather than a structure of function pointers.  This makes 
assignment of values _very_ easy to screw up.

2) type-opaque interfaces break C compiler pointer analysis.  This 
prevents alias optimization from working well, and also breaks checkers 
like the Stanford checker and sparse.  C gave the world a type system, 
we should use it.  :)

3) Uses and stores offsets to driver-private structures in generic code 
(iw_handler_def).  See #2 for pointer chasing/aliasing problems related 
to doing stuff like this.  Further, this is a massive layer / object 
lifetime violation.  The generic/core code should never need to know 
about a structure declared in a low-level driver.  That's backwards from 
the way information should flow.

It's not Jeff's weird personal preference that iw_handler be killed... 
type-opaque interfaces cause real problems.  A good C programmer should 
very, very rarely use type-casting.

	Jeff