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.
> 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.
In my 802.11 stack the 802.11 information structure can be
found given a generic device pointer. All the wireless info
can be retrieved from that, and you can use it to call the
wireless stack routines if you wish as well.
This is no different than how we keep ipv4 information hooked
onto the generic device structure and walk between these various
entities in the ipv4 and generic networking code.
Please read my skeletal stack code, it is exactly how I truly
believe something like this should be architected. It's all
the base layout stuff that's important, the rest are details
that will fit in cleanly and readily once you have a solid
and firm foundation.