Re: wireless: recap of current issues (configuration)

[Stuffed Crust <pizza@shaftnet.org>]

On Mon, Jan 16, 2006 at 10:00:18AM -0800, Sam Leffler wrote:
> Perhaps you haven't hit some of the more recent standards that place 
> more of a burden on the ap implementation?  Also some vendor-specific 
> protocol features suck up space for ap mode only and it is nice to be 
> able to include them only as needed.

While there is more work to be done on the AP side, and that code may
even be easily wrapped in an #ifdef, the majority of the complexity is
shared by both the station and the AP.  It's worth mentioning that the
802.11 specs do not generally differentiate between "APs vs non-APs" --
they're all "STAs" of equal capabilities.

This is at least true of 802.11d, 802.11e, 802.11i
(supplicant/authenticator notwithstanding), 802.11j, and 802.11k.  The
general difference is that the AP needs to be aware of the state of its
associated STAs, and perform different actions depending on configured
policy and the STAs' states, whereas the STAs generally do what the AP
tells them to do.

> There are several advantages to splitting up the code such as reduced 
> audit complexity and real space savings but I agree that it is an open 
> question whethere there's a big gain to modularizing the code by 
> operating mode.

I agree that there would be some space savings, but they'd be relatively
small, at least if the stack is designed to be generic.  This would make
the most difference for tiny/embedded systems -- but they'd want to use
#ifdefs to disable all AP code entirely, which includes all of the "if 
(ap_mode) { } else { }" clauses that would litter the whole codebase, 
regardless of modularity.  (then if we use function pointers... that's a 
*lot* of virtual functions..)

 - Solomon
-- 
Solomon Peachy        				 ICQ: 1318344
Melbourne, FL 					 
Quidquid latine dictum sit, altum viditur.

Attachment: pgpbumeCdNZOq.pgp
Description: PGP signature