Re: [RFC] Wireless extensions rethink

[Jeff Garzik <jgarzik@pobox.com>]

Jean Tourrilhes wrote:
> On Thu, Jun 17, 2004 at 02:23:01PM -0400, Jeff Garzik wrote:
> 
>>Jean Tourrilhes wrote:
>>
>>>	As a matter of fact, I tried the strongly type approach you
>>>advocate and find its kernel overhead not acceptable. Note that people
>>>not using wireless have to suffer from this bloat, and wireless
>>>extensions are used in embeeded platforms such as OpenAP, iPaq and
>>>Zaurus where footprint matters.
>>
>>As you can see from the patch and header I have attached, there is 
>>_zero_ change to storage.  No additional bloat.
> 
> 
> 	I've never talked of driver bloat, which I don't really care
> about. I'm talking of *kernel* bloat. And not about storage bloat, but
> code bloat.

Yes, I was referring to driver bloat not core kernel bloat.

Nonetheless, the type-safe interface would not be larger, and very 
likely will be smaller.


> 	When I designed the API, I did verify this carefully :
> 	http://marc.theaimsgroup.com/?l=linux-kernel&m=100829443600986&w=2

This WAS a step forward, and this will help greatly in the 
implementation of wireless_ops.  It's good stuff, but we are moving 
forward yet again :)


>>Sorry, keeping compatibility with drivers outside the kernel is _not_ a 
>>priority here.  Backward compatibility is how this cruft accumulated in 
>>the first place.
>>
>>Go ahead and assume that drivers outside the kernel will break.  This is 
>>no different from vendor drivers -- if the driver is not in the kernel, 
>>it doesn't exist.
> 
> 
> 	Jeff, this is not the way I work. For example, there are good
> reasons why the Atheros driver is outside the kernel.

Yes, but...  that's the way the Linux kernel works.

If a driver isn't in the kernel, it's the responsibility of the vendor 
to follow the changes in the kernel.  It's not the kernel developer's 
responsibility to track random stuff posted on web pages.  That's simply 
not scalable.

I imagine this is another area where we must agree to disagree.  Linux 
kernel development has always focused on in-tree drivers.

Wireless traditionally has had a lot of drivers out-of-tree -- and being 
out of tree, we see what happens:  vendors are encouraged to mixed 
binary-only drivers, multiple wireless stacks appears, and confusion 
reigned.

It's now time for convergence :)

	Jeff