Subject: Re: your recent ARP changes...
To: Ignatios Souvatzis <>
From: Fred L. Templin <>
List: tech-net
Date: 04/21/1997 17:38:14

Thanks for the explanation. As to your proposals, I agree that the right
solution is to leave a bare-bones netinet/if_ether.h file lying around
that has an arpcom struct with just the "struct ifnet ac_if" included,
and includes <net/if_ether.h>. (You may actually need to call it something
else like "net/if_enet.h" to differentiate the two files, and to remove
ambiguity wrt. the historical precedence that has been set.) This would
break all drivers which try to reference ac_enaddr, but would preserve
enough backwards compatibility to be reasonable. So, I think this would
yield an acceptable tradeoff level...



> Fred,
> the problem is not that we couldn't create a struct arpcom in a backwards
> compat include file just to have one...
> the problem is that drivers could think, as about 100 or so (which I
> transformed) did, that it contains an Ethernet address copy, and
> operate on it. (e.g., assume that all system components will look at
> it, etc.)
> They should use LLINFO(ifp->if_ladr) instead, of course, if ported to
> NetBSD-1.2D.
> That is: either we add that field to the compat_arpcom structure,
> making the software fail at runtime, or we don't add it, making the
> software fail at compile time. We have the latter already... 
> If anybody has a suggestion how to handle this, please speak up.
> We could make an netinet/if_ether.h, which
> - #includes <net/if_ether.h>
> - #defines ac_if ec_if, or does this through a fake arpcom definition.
> - contains a struct arpcom which encapsulates struct ifnet
> what did I forget?
> This won't work with real ethernet devices, however; they need to be
> ported (and should be).
> Btw: maybe its easier to write a compat module the other way round?
> Regards,
> 	-is