|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|
|References:||<firstname.lastname@example.org> <757AB580-0030-11D9-9224-000A95AD0668@errno.com> <email@example.com> <firstname.lastname@example.org>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312|
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:
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||[PATCH] unexport alloc_divert_blk/free_divert_blk, Christoph Hellwig|
|Next by Date:||Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack, David S. Miller|
|Previous by Thread:||Re: generic 802.11 stack, Luis R. Rodriguez|
|Next by Thread:||Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack, David S. Miller|
|Indexes:||[Date] [Thread] [Top] [All Lists]|