Re: [RFC] Wireless extensions rethink

[Jeff Garzik <jgarzik@xxxxxxxxx>]

Jean Tourrilhes wrote:
> On Thu, Jun 17, 2004 at 03:34:22PM -0400, Jeff Garzik wrote:
>
> > Your patch is half the job -- it allows development of a type-specific 
> > interface...
>
>
> 	Which is exactly what you want. Good.

The patch doesn't kill the type-opaque interface, so only 50% of what I 
want.


> > So while this patch may be useful in early development, it does not 
> > allow the direct exposure of core wireless code to the type-specific 
> > interfaces
>
>
> 	What is the core wireless code ?

At the moment, "the stuff that calls the driver-local iw_handlers", but 
hopefully more generic wireless core soon with the merge of HostAP.


> > and as such, it can paper over problems that would be 
> > immediately obviously if the type-specific interface were the only one 
> > to exist.
>
>
>         Any new code in the kernel is free to use only the new
> API. That's a big enoug incentive to migrate drivers over to the new
> API.

With the type-opaque interface gone (key design goal), drivers not using 
the new API will not function...


> > > > Also there is a fourth -- WE doesn't work 100% when you have 
> > > > a 32-bit userland and a 64-bit kernel.
> > >
> > >
> > >         Since when ? What made you change your mind ?
> > >         Please check :
> > > http://marc.theaimsgroup.com/?l=linux-netdev&m=107894322418086&w=2
> >
> > The general API, yes.  But most driver-private interfaces will fail 
> > miserably through 32/64-bit translation.
>
>
>         That's fixable, and easy to fix, if needed. You have all the
> data you need in the kernel.

Not really -- it's the same problem as SIOCDEVPRIVATE.  Driver-private 
interfaces by definition change for each driver.  Translation of the 
same ioctl differs on a per-driver basis.  Consider what happens when 
passing pointers from userland, for example...

It was for this reason that we created the MII ioctls, which were 
previously SIOCDEVPRIVATE.

        Jeff