Re: [RFC] Wireless extensions rethink

[Jeff Garzik <jgarzik@pobox.com>]

Jean Tourrilhes wrote:
> 	And guess what, I'm helping you in the process. Look back at
> all the e-mail I sent to the various thread on the subject, and you
> will clearly see that I'm constructive and giving suggestion on how to
> do best in this process. I even provide patches.
> 	I don't understand why you are so opposed to my suggestions,
> and what more you expect from me.
[...]
> 	Converging wireless into Linux since 1996. Welcome to the club ;-)

hehe  :)

I'm _not_ blaming you for anything.  You have certainly contributed a 
lot.  I've enjoyed working with you in the past, today, and hopefully 
into the future as well.  I _am_ listening.  But I think we have a 
fundamental disagreement:

I feel strongly (as you see :)) that the type-opaque interface has got 
to go, and that means breaking backwards compatibility in the driver API.

The iw_handler interface breaks rules of C that we shouldn't be 
breaking.  Today's kernel includes boatloads of reference-counted 
kobjects, with strict definitions of lifetime rules.  This has exposed 
endless bugs and caused a lot of pain, but overall it's a good thing to 
clean all that up.  Interfaces that store offsets into driver-local 
structures (iw_handler_def) violate these lifetime rules by simply 
assuming you always have access to the structure of choice.

We want to design driver interfaces that make it tough for the driver 
writer to screw up.  Excluding yourself, myself, and others on this 
list, I think we all know that driver writers can't code their way out 
of a paper bag.  A properly designed interface lets the compiler flag 
incorrect code at the first possible opportunity.  Current WE __does__ 
get the job done (kudos), but it simply doesn't afford that kind of 
protection.

	Jeff