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
|