So we have *multiple alternate* sources of information from which
to write a device driver for this card.  Someone explain to me why
we will not have a driver for it in NetBSD 1.6 ?

Given how long it will be before another NetBSD release (after 1.6),
I think excluding a driver for this card (amongst others) can only
do us more harm than good.  From what Jason has said, there has been
no commitment from Intel to do anyting about that situation and,
if anything, any bargaining power he might have had (at Zembu) is
much diminished now.  I don't see why our ability to ship with a
working driver has to be diminished because one of the many avenues
has been blocked.

Furthermore, until Jason can commit his driver, I cannot see any
reason why someone else should not commit theirs, so long as it
"works".  Now if that driver were to be removed without a replacement
added, that would be a problem.

Darren

In some email I received from Matthew Jacob, sie wrote:
> 
> It's not clear to me that Jonathon's driver is really unencumbered. He had
> access to Intel docs via Cisco. It's not clear to me how he was then
> authorized to release if_gx.


> Anyway, as I said, I've lost interest in the chip itself. It's too hard to try
> and work separate from Intel. If they want to help- that's actually great, I
> guess! If not, they make it too difficult to use their h/w and still leave
> room for an Open Source driver. I've given up on that route myself. It's
> *sooo* much nicer dealing with companies like Sundance or LSI-Logic- they
> simply just give you information and you can happily support their products.
> 
> -matt
> 
> 
> On Thu, 14 Mar 2002, Jonathan Stone wrote:
> 
> > 
> > >Actually, there *was* a driver (unencumbered by the author signing NDAs)
> > >almost ready to go over a year ago. Jason specifically asked me to not commit
> > >it. I've been (perhasp overly) respectful of that since then. In the mean
> > >time, the author has lost interest in working on this h/w, but others should
> > >feel free to swipe the current instantiation from OpenBSD and DTRT if their
> > >timer interrupt says "Intel releasing Jason has taken too long".
> > 
> > >It's also possibly true that the current 'lead' driver resident in FreeBSD
> > >(which is done by an Intel engineer, actually: Prafulla Deuskar
> > ><pdeuskar@FreeBSD.ORG>), could be ported for NetBSD. The trouble with this
> > >driver is that it appears to be a port from Linux and cleaning it up to be
> > >acceptable for the different platforms that NetBSD has might require more time
> > >investment than he or Intel is willing to make.
> > 
> > And then there's the *third* FreeBSD driver, if_gx.c by Jonathan
> > Lemon. That driver addresses most of the design issues Jason raised
> > with your driver (some of which I know have been fixed since).  The
> > rxeof and tx routines in if_gx.c look awfully like some of Bill Paul's
> > FreeBSD drivers, which have already been bus-dma-ified and imported
> > into NetBSD.
> > 
> > Intel's stance on licensing drivers for their gig-E cards looks just
> > plain silly, and it can only be hurting them in the marketplace.
> > Whether they see it that way or not is another story, though :).
> > 
> 
> 
>