On Wed, Oct 23, 2002 at 09:18:00PM -0700, David S. Miller wrote:
> I'm not allowing you to put a hack special ARP header type into
> the kernel when the real fix is to clean up the 802.11 handling
> in the entire tree.
It's not so much a matter of "clean up" as "write to begin with"
> This is the second time I'm saying this.
And this is the second time I'm saying that I agree that it is the wrong
thing to do; I don't want to do it; I withdraw my request for the new
ARPHRD type; and again ask the question:
Do the network core &| protocol stacks have any dependencies on
(skb->mac.raw - skb->data) being the same as netdev->hard_header_len?
I'm asking you if the core networking stuff can handle variable-length
headers coming off of one netdev.
Can I assume it generally works, or is it generally broken? You seem to
be implying the latter.
> If that means every ethernet driver has to be aware of variable length
> headers potentially, so be it.
The ethernet drivers are not broken. The generic ethernet code is not
broken. 802.11 headers are not a "special case" of 802.[23] headers.
If anything is broken wrt variable headers, it would be net/ipv4 or
some other protocol stack.
So, what do you want me to do?
0) go away
1) audit the use of hard_header_len in net/* and submit fixes
2) write an 802.11 equivalent of the code in eth.c
3) mangle eth.c to handle 802.11 &| variable headers and fix all
drivers that inevitably break
Bleh.
- Pizza
-- Solomon Peachy solomon@linux-wlan.com AbsoluteValue Systems http://www.linux-wlan.com 715-D North Drive +1 (321) 259-0737 (office) Melbourne, FL 32934 +1 (321) 259-0286 (fax)
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:23 EST