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

[greg chesson <greg@xxxxxxxxxxx>]

Oh really?

What about eth_type_trans()?
It is not implemented as a true network stack.
Many drivers call it, but it is a gross input packet
hooked eater thing that's an ugly wart bolted onto the
side of the driver API.

what's good for the goose, etc.

My point is that there is ample precedent in the OS for common
 driver "assistance" subroutines that contain protocol knowledge or 
implement
policy yet are not implemented in strict stack-like manner
because it didn't make sense to do 'em that way.

It seems to me that Sam's net80211 code is performing three essential
functions:
1. encap/decap service for converting between 802.3 and 802.11
2. the MLME protocol (802.11 management messages and state keeping)
3. interface to upper layer ioctl stuff, particularly user-land crypto 
supplicants
    and authenticators in addition to the usual group of tools.

The MLME protocol works as a stack already since it really does 
implement a protocol.
The encap/decap could be implemented stack-like instead of 
eth_type_trans-like,
but it seems very suboptimal to do it another way.   The ioctl 
interfaces are a wart on the side
of the driver API anyway, but let's not have an argument about that 
since it is
a design feature of the OS inherited from unix.

The complaint seems to be mainly about the encap/decap procedures
which are implemented more as driver helper functions.
If somebody wants to rewrite them as a stack, then go for it.
I'll be interested in seeing whether or not good methods can be found
for exporting driver-local information (e.g. the mac address of the AP,
or the tx PHY rate needed to calculate the duration field value,
or whether or not to do mac tx fragmentation, etc)
up the stack without creating a pile of spaghetti to rival Microsoft's
failed "native 802.11" project.

I've thought about this problem and don't think there is a good answer
if a layered approach to protocol implementation stipulates that each layer
be self-contained.    The 802.11 situation requires more data-sharing
between layers than is conducive to a strict layering approach.
I suspect that what's needed is a data structure tailored to wireless
which can be shared between layers and common across devices.
Perhaps it could be an extention to dev (wdev?) that captures
the necessary sharing.    But the problems don't stop there.
Think for a moment about where power-save should be implemented -
which layer?

cheers,

g





Sam Leffler wrote:
> On Monday 06 September 2004 06:23 pm, David S. Miller wrote:
>
> > On Mon, 6 Sep 2004 11:13:31 -0700
> >
> > Sam Leffler <sam@xxxxxxxxx> wrote:
> >
> > > I've suggested this code as a good starting point for a "generic 802.11
> > > stack" but received only misinformed responses.
> >
> > Sam, I've told you multiple times why your stack isn't a good
> > starting point.  It isn't implemented as a true network stack,
> > like IPV4, Appletalk, etc.  Instead it's a gross input packet
> > hooked packet eater thing that's an ugly wart bolted onto the
> > side of the driver API.
>
>
> Actually, this is the first time you've said anything to me about this code.  
> We corresponded intensely for about a week 2+ years ago after which you 
> declared you now knew how to "write an 802.11 stack right" and were going to 
> do it that weekend.  I waited but it seems the sum total result was the shell 
> of code that Jeff referenced in a previous note.
>
> Perhaps you can point me at a description of what a "true network stack" means 
> to you.  I'm guessing this has to do with your wanting queues inserted at 
> various places instead of direct handoffs.  Regardless, I've never suggested 
> the current code is suitable as-is but rather should be reshaped to suit the 
> intended structure of the system.  There is a lot of hard-earned experience 
> in the code that is independent of coding style and operational 
> infrastructure.
>
> Anyway, the point of my note was to correct a comment in the original posting 
> and make folks aware that working code existed from which they could crib 
> stuff.  Good luck finding someone to reimplement eveything according to your 
> wishes.
>
> 	Sam