[wpa-supplicant] Wireless-extension v19

[Jean Tourrilhes]

On Mon, Sep 19, 2005 at 10:57:39PM -0700, Jouni Malinen wrote:
> On Mon, Sep 19, 2005 at 10:07:52AM -0700, Jean Tourrilhes wrote:
> 
> > 	Ok, that's a bug and that's fixable. I mananaged to do it in
> > WT, so there must be a way. Let me think 2 sec about it.
> 
> Of course it can be fixed, it just means that all user space programs
> using scan results or wireless extensions need to have support for
> multiple formats..

	Or they need to use libiw (hint, hint ;-).
	Yeah, I agree that it's not cool. But, if you take the long
term perspective, in one year it won't matter anymore. Do you remember
the big user-space change that happened between WE8 and WE-9 ? Also,
over time, there was many tiny change to the user-space API (like
adding length to set requests) which I had to take care of, and now
all of that is forgotten.

> > 	Let's not overreact. API changes happen all the time.
> 
> API changes in kernel are perfectly fine to me, but this sounds like a
> kernel-userspace ABI change which is not okay without a good reason.
> Fixing something that is broken on systems with 64-bit kernel and 32-bit
> user space is a good reason, though.

	Well, if you remember, Jeff wanted to throw away completely
the Wireless Extensions and provide a new user space API. Some user
space API are very stable (for example ifconfig ioctls), while others
are changing all the time (ethtool ioctls).
	On the other hand, you sometime complain about legacy stuff in
the WE, for example about the fact the essid.len = strlen(essid) + 1;
	My mistake was that I assumed that wpa_supplicant was using
iwlib while it was not. I did check many other apps for those changes
and warned the maintainers about it, like I always do with such
changes, but I forgot you. My mistake.

> > 	Yes, I believe so. Having a pointer in there doesn't make the
> > event format 32/64 bit clean, if you use a 32 bit userspace with a 64
> > bit kernel you will end with potential trouble.
> 
> Is anything using that pointer in scan result or wireless event parsing?
> Or is the 32/64 issue in just having an extra variable that has a
> different length in kernel and user space? I haven't looked into details
> of how this is done, so this is somewhat unclear to me.

	If the kernel is 64 bit, a pointer is a 64 bit entity. If its
user space is 32 bit, pointers are 32 bits entity, which mean not the
same size and not the same alignement. Most ioctls are converted (see
linux/fs/compat_ioctl.c - note that this file was not updated with
WE-18 ioctls). I could have tried to convert the payload of event and
scan, but that would have been quite ugly, and as the pointer is not
used anyway, it was cleaner/easier to just remove it.

> On Mon, Sep 19, 2005 at 11:52:39AM -0700, Jean Tourrilhes wrote:
> 
> >       Attached is a revised patch. I took a slightly different
> > approach this time, just to make things more interesting. This patch
> > is not tested, not even compiled, but will give you some rough
> > idea. It should work for both WE-19 and WE-18, and should compile with
> > either WE-18 or WE-19.
> 
> Thanks! Being able to compile driver_wext.c with WE-18 is not needed, so
> I removed that part. And I noticed that this was not compiled.. That
> statement about should compile with either version is somewhat
> optimistic ;-).

	Yeah, I meant "once all the bugs are fixed, it might be
possible to compile it with both versions".

> I ended up modifiying this a bit by not using memmove() separately on
> the temporary buffer, but just changing the initial copying of the data
> to copy stuff from the correct location.

	That's much close to the way iwlib.c does it, actually.

> Anyway, the end result is pretty much identical. This patch is attached.

	Looks good.

> I was about to commit this to CVS, but remembered that hostapd has the
> exact same issue, so wireless_copy.h is not going to change before both
> programs can be fixed at the same time. This is the part I don't like
> about ABI changes.. ;-)

	I expect hostapd to be even easier...

> >       By the way, SIOCGIWRANGE also change and may break your code,
> > I added code that should workaround those API changes.
> 
> Thanks!

	My pleasure...
	Have fun...

	Jean