Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[greg chesson <greg@atheros.com>]

You guys are too serious and, I believe, missed the real points.

1.  There is a need in the OS for a "service" to convert between
       .11 and .3 packet formats.   It should be designed for 
hw-independence.
      Everyone sees the same potential for unification
       of wireless drivers.

2.  It's harder to do than it first appears because the complete
      transformation from .3 to .11 cannot be done in isolation
      from the driver(s) and there are monkey wrenches that get
      tossed in from crypto, interaction between crypto and fragementation,
      power-save, observing txoplimits, and other things that tend
      to cross architecture lines that would otherwise be nice and clean.

3.  I personally don't have religion about whether a service
      that transforms headers is implemented as a stack or implemented
      as a side call.   I think that a variety of factors are worth 
considering.
      In this particular case (header transformation), I believe a side call
      "helper function" is appropriate and has less overhead than the full
      protocol stack mechanism.   But it's pointless to argue about it 
without
      measurements.

4.  David's skeleton code is quite interesting and a good start.
       You won't know its usefulness until someone tries to implement
      a real driver.

g



jamal wrote:
> On Tue, 2004-09-07 at 13:10, David S. Miller wrote:
> 
>>On Tue, 07 Sep 2004 10:03:41 -0700
>>greg chesson <greg@atheros.com> wrote:
>>
>>
>>>What about eth_type_trans()?
>>
>>It determines the protocol type from the ethernet header
>>fields.  It is a simple shorthand header field fetcher,
>>not a protocol stack.
>>
>>You would need a eth80211_type_trans() for wireless
>>drivers too, and surprise surprise my skeleton 802.11
>>stack code in fact does exactly this.
> 
> 
> Or as Andi has been suggesting for sometime, not invoke it all ;->
> This is possible if the DMA descriptor already has all the info
> needed (quiet a few modern hardware can be programmed to do this).
> .. er, at the driver level. So this is not "a gross input packet
> hooked eater thing that's an ugly wart bolted onto the
> side of the driver API.";->
> 
> cheers,
> jamal
> 
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click