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