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
|