Perry,

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

I've just thrown approx. 3000 lines of new code at a HIPPI driver
including writing my own DMA mapping routines, PCI bus and register
access code, etc. etc. so I know wherein lies the complexity of driver
development. But I view that as a necessary evil as opposed to broken
backwards compatibility in the new ARP code, which I view as an annoyance.
(Also, this is just as far as the driver is concerned; what *really*
worries me is application portability.)

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

Yes, I'm definitely supportive of architectural improvements - for
example, I love the generic list and queue manipulation macros defined
in "<sys/queue.h>". In the case of the ARP changes, I'm definitely
supportive of a cleaner architecture - but if backwards compatibility
is easy I think it should be done.

> 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

Thanks,

Fred
templin@nas.nasa.gov