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)