Hello Ignatios,

My name is Fred Templin, and I work with Jason Thorpe at the NASA
Ames Research Center. I've been porting a HIPPI network device driver
suite (kernel-level driver plus supporting app's) to "netbsd-current"
and was chugging along just fine 'till your ARP changes hit the pool.
Then (obviously) my build broke and I was suprised to learn that both
"netinet/if_ether.h" was moved into "net" and the "arpcom" data structure
has disappeared from the source tree alltogether. From speaking with Jason,
I think I understand your motivations for the changes that went in and 
it seems to me like your goals included creating a cleaner architecture;
which is good. But, I'm afraid you may be setting yourself (and NetBSD)
up for a long-term source code porting nightmare that won't go away
anytime soon.

Very basically, all OS's derived from 4.*BSD have had the arpcom and
ether_header data structures married together in the "netinet/if_ether.h"
module since the beginning of time. When new datalinks like FDDI started
popping up which included similar (IEEE 802-style) MAC headers to Ethernet,
folks leveraged off the existing modules and data structures rather than
architecting a datalink-independent solution. Now, I'm not saying that
this was a good thing - in fact, I'll agree that "if_ether.h" should
have lived in the "net" directory and the ARP-related data structures
moved into a different module from the very beginning. But the fact is
that the other 4.*BSD-derived OS's have maintained the original module
names and data structures, and changing this in NetBSD now - while
architecturally clean - is only going to make NetBSD appear to be broken
in relation to the other OS's.

By way of example, in my case I'm working with a source distribution
from Essential Communications which includes a network driver suite and
supporting applications for a HIPPI/PCI card. Because the Essential guys
took a kitchen-sink approach to their development effort, their source
distribution includes approx. 100K lines of code - much of which deals
directly with the datalink-related  data structures. The driver supports
Digital UNIX, three different versions of SGI IRIX, HP-UX, and AIX, while
the supporting applications support all of the above plus WIN95 and NT.
And, in all of these supported OS's (except the Microsoft OS's, that is),
the "if_ether.h" module is included as "<netinet/if_ether.h>" and the 
"arpcom" structure is used as the handle by which the driver finds the
"ifnet" struct. For me to change that for the NetBSD port now would cause
me to add hundreds of lines of the form:

  #if defined(__NetBSD__)
  struct ifnet *ifp = (struct ifnet *)&(sc->is_ec.ec_if);
  #else /* defined(__NetBSD__) */
  struct ifnet *ifp = (struct ifnet *)&(sc->is_ac.ac_if);
  #endif /* defined(__NetBSD__) */

in the kernel code. This isn't as bad as the fact that a large number
of the supporting applications also include "<netinet/if_ether.h>", and
heaven knows what data structures they once accessed from that module
which will no longer be available to them. (Not to mention that the
module has been moved to a new directory!)

In any event, my main point in this is that I don't see any problem
with your architectural change to separate ARP out from the specific
datalink headers. But, I would strongly advocate a "backwards-
compatibility" approach, in which the traditional directory hierarchy
and data structure names are preserved. For example, I would recommend:

	1) leave "if_ether.h" under "netinet"
	2) add comments like crazy to the effect of:

	  "THIS FILE IS HERE FOR COMPATIBILITY PURPOSES *ONLY*"

	3) create a new module called something like "net/if_enet.h",
	   and move the Ethernet-related data strucutures there
	4) change the old data structures in if_ether.h (such as arpcom)
	   to include opaque pointers to generic underlying datalink
	   objects, which are defined in the new modules you've added
	   such as "net/if_arc.h", "net/if_atm.h", etc.

In this way, application and kernel code portability will be preserved,
folks will know by reading the comments in "netinet/if_ether.h" that
you've cleaned up the architecture w/o breaking backwards compatibility,
and NetBSD will be perceived as being ahead of the game w.r.t. the other
OS's by those in the know.

Thankyou for your time,

Fred
templin@nas.nasa.gov