Thread (13 messages) 13 messages, 7 authors, 2004-06-04

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help