Re: [PATCH net-next 0/15] Neighbour table and ax25 cleanups

[David Miller <davem@davemloft.net>]

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Sun, 01 Mar 2015 23:59:11 -0600

> While looking at the neighbour table to what it would take to allow
> using next hops in a different address family than the current packets
> I found a partial resolution for my issues and I stumbled upon some
> work that makes the neighbour table code easier to understand and
> maintain.
> 
> Long ago in a much younger kernel ax25 found a hack to use
> dev_rebuild_header to transmit it's packets instead of going through
> what today is ndo_start_xmit.
> 
> When the neighbour table was rewritten into it's current form the ax25
> code was such a challenge that arp_broken_ops appeard in arp.c and
> neigh_compat_output appeared in neighbour.c to keep the ax25 hack alive.
> 
> With a little bit of work I was able to remove some of the hack that
> is the ax25 transmit path for ip packets and to isolate what remains
> into a slightly more readable piece of code in ax25_ip.c.  Removing the
> need for the generic code to worry about ax25 special cases.
> 
> After cleaning up the old ax25 hacks I also performed a little bit of
> work on neigh_resolve_output to remove the need for a dst entry and to
> ensure cached headers get a deterministic protocol value in their cached
> header.   This guarantees that a cached header will not be different
> depending on which protocol of packet is transmitted, and it allows
> packets to be transmitted that don't have a dst entry.  There remains
> a small amount of code that takes advantage of when packets have a dst
> entry but that is something different.

Wow... simply, wow.

I thought we'd be stuck with that crap forever, great work!

Applied to net-next, thanks again!