On Thu, 2007-03-08 at 14:11 -0800, Jean Tourrilhes wrote: > First possiblity, we could stick with this band-aid > permanently. It sucks for various reasons, one for example being that I don't even understand your recognition code but all userspace programs that use wext will have to include such code! > Second possiblity : we do the right thing and plan a API > change to return struct always aligned on 32 bits. This way, when we > get 128 bit processor, we don't have to add another band aid ;-) > It would work like the ESSID changeover. We pick a WE version > changeover. We introduce userspace that can deal with before and > after. After 1 or 2 years, we flip the switch. After another 1 or 2 > years, we get rid of backward compatibility. Probably doesn't make much sense, we might as well schedule wext for removal by then and just make the effort to replace at least for all IEEE 802.11 hardware. And then we rip out the compat ioctls completely (just deny them) so if someone's stupid enough to use really really old hw in new machines (where that even works) they need a 64-bit userspace. > Third possibility : we declare 32 bit userspace on 64 bit > kernel as not supported and advise users to get a 64 bit > userspace. The number of bug report on that issue would suggest that > very few users are in this case. Randy is right here, most a lot of powerpc64 users don't bother compiling 64-bit userspace apps since there's not much point in it. Also, a lot of distros don't even distinguish between powerpc32 and powerpc64 so debian for example can't possibly fix this by shipping 64-bit versions of the affected tools. Besides, a 64-bit network manager couldn't integrate with gnome-panel I'd think. The only real fix to me is fixing it in the kernel, but as you say that's very icky. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
