David Miller [off-list ref] writes:

From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 03 Mar 2015 09:41:47 -0600

quoted

Before the ax25 stack calls dev_queue_xmit it always calls
ax25_type_trans which sets skb->protocol to ETH_P_AX25.

Which means that by looking at the protocol type it is possible to
detect IP packets that have not been munged by the ax25 stack in
ndo_start_xmit and call a function to munge them.

Rename ax25_neigh_xmit to ax25_ip_xmit and tweak the return type and
value to be appropriate for an ndo_start_xmit function.

Update all of the ax25 devices to test the protocol type for ETH_P_IP
and return ax25_ip_xmit as the first thing they do.  This preserves
the existing semantics of IP packet processing, but the timing will be
a little different as the IP packets now pass through the qdisc layer
before reaching the ax25 ip packet processing.

Remove the now unnecessary ax25 neighbour table operations.

Signed-off-by: "Eric W. Biederman" <redacted>

Another nice cleanup, applied, thanks Eric.

We can almost universally use the same procedures for generating
link layer headers from neighbour table entries now.  I had hoped
to optimized things by removing function pointers.

The big hold out is DECnet that sets src_mac based on the DECnet source
address.  

Which leads me to the conclusion that since DECnet has a different
algorithm for setting the src_mac than everything else in the kernel
DECnet neighbour table entries can not be used for nexthops for other
protocols :(

DECnet also abuses neigh->output to select by output device which kind
of DECnet header to put on the packets.  But that is easily fixable.

Anyway slowly slowly the neighbour table code becomes more readable
and maintable.

Eric