Fred L. Templin writes:
> 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.

Yup. We now have a generic ARP subsystem, so we can support arp over
Ethernet, ARCNet, ATM, radio protocols, etc.

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

I recently worked with a couple of people to do a midnight port of a
BSDI NCR WaveLan driver to NetBSD. Compared to the effort needed to
deal with things like making it grok the bus space stuff and the
effort needed to deal with differing device attachment, the couple of
lines that had to be changed to deal with this were really minor.

Certainly NetBSD is very different from other BSDs at this point --
we've built a very clean infrastructure for doing things like running
identical drivers across many radically different architectures and
the like, and this does mean that stuff no longer works "out of the
box". You win some you lose some.

Maybe you are right that some back compatibility stuff would be of
use, but it really wasn't that big a deal to make the change (at least
from what I could tell). I certainly wouldn't *oppose* back compatible
includes and such, but...

Perry