Dennis writes:
> 
> Is 1.4 going to be so different from 1.3.3 that we should bypass what is
> currently
> stable? Its only a minor release (unless you use a different numbering
> system then
> the rest of the world), so why are you implying that it would be a waste of
> time to
> port to 1.3.3? 

Hello,

My suggestion would be to port to 1.3.x, and design your device driver
such that the low-level hardware access routines can be split off from
the layer 2 code.  A barebones device driver for an ET sync board could
be donated to the "open source" world (under a BSD copyright), and would
very likely be integrated into the NetBSD source tree.  All of the
Frame-Relay smarts could perhaps be implemented via a LKM that communicates
with the low-level driver.  Hopefully OS release specific issues would
be less troublesome. 

A basic device driver that supported straight sync communications, for
PPP or Cisco HDLC would be a nice addition, IMHO, to NetBSD.  Having the
ET cards being the "only supported" sync card should be worth something.

With this scenario your advanced frame-relay driver doesn't need to be
released in source, yet it would be very easy for customers to load the
additional value added drivers.

Myself, I tend to see the NetBSD/i386 supported hardware list as a good
reference, even if the hardware I want to buy isn't for NetBSD.  Why
not buy a card supported by NetBSD than one that isn't, "Just In Case."

So something like this in /usr/src/sys/arch/i386/GENERIC:

	et*	at pci? dev ? function ?	# Emerging Tech. Sync Cards

This would cause me to look into buying this brand of sync card, even for
other projects, simply because it is supported under my favorite OS.

Anyway, just some thoughts.

-Andrew
-- 
-----------------------------------------------------------------
Andrew Gillham                            | This space left blank
gillham@whirlpool.com                     | inadvertently.
I speak for myself, not for my employer.  | Contact the publisher.