Re: Prism54 WPA Support - wpa_supplicant - Linux general wpa support
From: Jean Tourrilhes <hidden>
Date: 2004-06-03 17:08:11
Also in:
lkml
On Thu, Jun 03, 2004 at 12:06:35AM -0400, Jeff Garzik wrote:
One of the things that is nice about wireless-2.6 is that is affords the opportunity to totally rethink the wireless extensions. Although a lot of people would howl, since HostAP is essentially new code from the mainline kernel perspective, a new userland API (and new or updated tools) could come along with it. I have mentioned in the past (no offense Jean!) that I do not like the overly-generic wireless handler structure. It is less type-safe than is generally preferred in Linux, IMO. A low-level wireless driver should not implement ioctls, it should implement callbacks in some sort of 'struct wireless_operations' as is done in other kernel subsystems. ioctl details should be hidden from low-level drivers as much as possible, through type-safe interfaces. Strive to make both the wireless driver API and the wireless userland API easy to change and evolve over time. Jeff
Jeff, I'm amazed that you are so obsessed with this. Yes, Wireless Extension could be improved in millions ways, but at least it's working, whereas there are so many other areas where we have nothing at all. If you talk with most people developping wireless drivers, this doesn't even make their list. But I guess every one of us need to have his hot topic ;-) I believe most people are concerned about : o WPA support (and security API in general) o SNAP encapsulation/decapsualtion in kernel o handling 802.11 frames natively in kernel o handling 802.11 management in kernel (association/deassociation, ...) Personally, those are my priorities : o getting more wireless drivers in the kernel o RtNetlink API for Wireless Extensions I also explained you how you could wrap around Wireless Extension trivially to introduce a new driver API without breaking the many user space tools, so that you can implement your proposal with maximum backward compatibility. Just because there is one aspect of the API you don't like, we don't need to throw away the good parts. Have fun... Jean