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

[greg chesson <greg@xxxxxxxxxxx>]

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@xxxxxxxxxxx> 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