[Top] [All Lists]

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

To: Sam Leffler <sam@xxxxxxxxx>
Subject: Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack
From: greg chesson <greg@xxxxxxxxxxx>
Date: Tue, 07 Sep 2004 10:03:41 -0700
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, vda@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, jgarzik@xxxxxxxxx, netdev@xxxxxxxxxxx, acx100-devel@xxxxxxxxxxxxxxxxxxxxx, jt@xxxxxxxxxxxxxxxxxx, jkmaline@xxxxxxxxx, prism54-devel@xxxxxxxxxxx
In-reply-to: <>
References: <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
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
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?



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.


<Prev in Thread] Current Thread [Next in Thread>