Vladimir Kondratiev wrote:

Greg,
you missed one important point. Besides data packets, that every driver now 
convert .11<->.3 using almost the same code, there is whole story of 
management. Many modern cards are "softmac" and do all management on host. I 
see no point for every driver to implement its own scanning and association. 

Yes, Quite right.  No disagreement.
It is standard practice on NDIS and Apple Darwin that a common GUI-based
application controls scanning, association, and manages 
keys+authentication+crypto.

Linux does the same thing (driver is configured by application code)
  although there does not yet exist a single app
that can serve as a common point of control for multiple vendor drivers.
I believe that achieving that goal is the real payoff for wireless Linux 
users.

It is simply waste of resources.

To make step forward, I suggest the following:

1. Dave's code is at least year old. someone need to start maintain it, 
starting with update for current kernel infrastructure. Get it compile and 
load for 2.6.9, for example.

2. To debug stack, you don't need real driver. I can write dummy .11 driver 
that will silently discard all Tx, and will provide some way for user level 
tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it 
is sufficient. Later, when it will come to timing, performance etc, it will 
be easy to strip some real driver.

This may be king of "proof of concept".

Yes, for logic it is sufficient.
My personal approach would be to test the theory by examining
what fits or doesn't fit into David's API if I were to port one of the
MLME implementations that I work with.   Discover if it fits or not.

Vladimir

On Wednesday 08 September 2004 19:02, greg chesson wrote:
gc> You guys are too serious and, I believe, missed the real points.
gc>
gc> 1.  There is a need in the OS for a "service" to convert between
gc>        .11 and .3 packet formats.   It should be designed for
gc> hw-independence.
gc>       Everyone sees the same potential for unification
gc>        of wireless drivers.
gc>
gc> 2.  It's harder to do than it first appears because the complete
gc>       transformation from .3 to .11 cannot be done in isolation
gc>       from the driver(s) and there are monkey wrenches that get
gc>       tossed in from crypto, interaction between crypto and
 fragementation, gc>       power-save, observing txoplimits, and other things
 that tend gc>       to cross architecture lines that would otherwise be nice
 and clean. gc>
gc> 3.  I personally don't have religion about whether a service
gc>       that transforms headers is implemented as a stack or implemented
gc>       as a side call.   I think that a variety of factors are worth
gc> considering.
gc>       In this particular case (header transformation), I believe a side
 call gc>       "helper function" is appropriate and has less overhead than
 the full gc>       protocol stack mechanism.   But it's pointless to argue
 about it gc> without
gc>       measurements.
gc>
gc> 4.  David's skeleton code is quite interesting and a good start.
gc>        You won't know its usefulness until someone tries to implement
gc>       a real driver.
gc>
gc> g
gc>
gc>
gc>
gc> jamal wrote:
gc> > On Tue, 2004-09-07 at 13:10, David S. Miller wrote:
gc> >
gc> >>On Tue, 07 Sep 2004 10:03:41 -0700
gc> >>greg chesson [off-list ref] wrote:
gc> >>
gc> >>
gc> >>>What about eth_type_trans()?
gc> >>
gc> >>It determines the protocol type from the ethernet header
gc> >>fields.  It is a simple shorthand header field fetcher,
gc> >>not a protocol stack.
gc> >>
gc> >>You would need a eth80211_type_trans() for wireless
gc> >>drivers too, and surprise surprise my skeleton 802.11
gc> >>stack code in fact does exactly this.
gc> >
gc> >
gc> > Or as Andi has been suggesting for sometime, not invoke it all ;->
gc> > This is possible if the DMA descriptor already has all the info
gc> > needed (quiet a few modern hardware can be programmed to do this).
gc> > .. er, at the driver level. So this is not "a gross input packet
gc> > hooked eater thing that's an ugly wart bolted onto the
gc> > side of the driver API.";->
gc> >
gc> > cheers,
gc> > jamal
gc> >
gc> >
gc> >
gc>
gc>
gc>
gc