Ignatios,

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...

Regards,

Fred
templin@nas.nasa.gov    

> 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