>From jonathan@DSG.Stanford.EDU  Fri Apr 18 15:42:36 1997
To: templin (Fred L. Templin)
To: ignatios@cs.uni.bonn.de, is@netbsd.org
Subject: Re: your recent ARP changes...
Cc: thorpej, kml, tech-net@netbsd.org
Date: Fri, 18 Apr 1997 15:41:36 -0700
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>

Jonathan,

Thanks for your input. A couple of comments:

> it looks to me like a substantial chunk of the problemsa you describe
> would be subsumed by
> 
> 	#include <net/if_ether.h>
> 	#define ac_if	ec_if
> 
> What happens when you try creating a <netinet/if_ether.h> containing
> the above?

Good suggestion, but I needed to add a couple of extra lines to make
it look like this:

  #include <net/if_ether.h>
  #include <netinet/if_inarp.h>
  #define arpcom ethercom
  #define ac_if   ec_if

Even then, I immediately got the following compile-time warnings:

  cc1: warnings being treated as errors
  if_ess.c: In function `ifess_if_ioctl':
  if_ess.c:159: warning: passing arg 1 of `arp_ifinit' from incompatible pointer type
  if_ess.c: In function `ifess_if_output':
  if_ess.c:304: warning: passing arg 1 of `arpresolve' from incompatible pointer type

because the arguments to the arp* routines have changed from "struct arpcom *"
to "struct ifnet *". So, it's not quite so simple (but do-able) in the
drivers, and who know what sort of compatibility issues are likely to
pop up in applications which traditionally included "<netinet/if_ether.h>"??

> But now the changes are done, I for one agree that better backwards
> compatibility with both NetBSD 1.2 and with other 4.4BSD-based systems
> is a good idea, and something NetBSD should at least aim for.  If
> people have gone to the effort of porting third-party drivers to
> NetBSD, the least we can do is ease the pain of supporting both 1.2
> and current in such drivers.

I agree, and I would extend this to easing the pain of supporting 1.2,
current, *and* all the myriad 4.*BSD-derivative OS's out there which
still have the legacy framework.

Regards,

Fred
templin@nas.nasa.gov