Messages in this thread | | | Date | Tue, 3 Oct 2006 19:16:48 -0400 | From | Theodore Tso <> | Subject | Re: wpa supplicant/ipw3945, ESSID last char missing |
| |
On Tue, Oct 03, 2006 at 05:40:44PM -0400, John W. Linville wrote: > Unfortunately, I don't see any way to "fix" WE-21 without similarly > breaking wireless-tools 29 and other "WE-21 aware" apps. And since > I'll bet that the various WE-aware apps have checks like "if WE > > 20" for managing ESSID length settings, we may have painted ourselves > into a korner (sic).
OK, I'm going to ask a stupid question. Why is the kernel<->wireless driver interface have to be tied to the userspace<->wireless interface? The first is internal to the kernel and is free to change, and if it breaks out-of-tree drivers, I'll complain to Intel about why the !@#@ the ipw3945 driver hasn't been merged, but we've never made any guarantees about break out-of-tree drivers, so I wouldn't have the right to complain to anyone else.
The second is an external userspace ABI, and that should remain constant. It sounds like right now one gets pushed straight out to the other, but what if the wireless infrastructure layer in the kernel provided "interface glue" so you can translate between multiple interface versions --- and then force the userspace (or at least new versions of the userspace) to declare to the kernel what version of the interface they are expecting?
That's what we do with the stat system call. Userspace tells the kernel whether they want the v1, v2, v3, v4, or v5 version of the stat structure, and we have interface glue to support all of the old versions.
Is there some reason why this would be too hard to do with the current interface? Or is the arguement that if you're going to invest that much energy in fixing the userspace interface code, you would rather go to d80211/nl80211?
Regards,
- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |