On Tue, Aug 08, 2000 at 09:32:24AM -0400, Dave McGuire wrote:
> On August 8, Jon Lindgren wrote:
> > I know that no sbus FDDI cards are supported, and I believe it was due to
> > lack of docs on the chipsets.

I know there has been additional information on the mailing list about
the sbus FDDI cards, but I'll throw in a couple of points of information
since nobody else seems to know this stuff.

Sun has shipped a variety of sbus based FDDI cards in the past.
My personal experience with these cards revolves around 2 models of
the cards:

	1) X1025A - SAS FDDI sbus card (single SC connector)
	2) X1026A - DAS FDDI sbus card (dual SC connectors)

These are the cards that Sun still sells -- the so-called version 5.0
cards.  They replaced the version 4.0 cards, which were programmatically
identical, but used MIC connectors instead of the SC connectsion.
Due to the size of the MIC connectors, the DAS MIC cards was double-wide
sbus card.

These cards are manufactured by Network Peripherals, Inc.
(https://www.npix.com)

> > I can't see why Sun shouldn't release info about these, especially given
> > many company's new found embrace for open source... perhaps a bit of slick
> > talking, pseudo beers and grumbling on my knees will get docs for some of
> > these chipsets.  And that'd certainly make us FDDI people scream with joy.

[...]

>   As I understand it, the bulk of the problem is that the
> manufacturers of the Sbus FDDI interfaces were complete idiots and
> did lots of the FDDI protocol stuff in the device driver, not on the
> card.  I don't know about you, but I've got *other* work for my
> SPARC processor to do...the network interface hardware is supposed to
> handle the damned wire protocols.  So these Sbus FDDI cards have dumb
> hardware and a HUGE device driver...for [puke] Solaris.

The real problem here is that the SMT implementation (which is not,
as stated, a proper part of the "wire protocols", but rather the
FDDI state machine that runs on top of said protocols) isn't part of
Sun's intellectual property.  They cannot release the code even if
they wanted to -- at least not without cutting a deal with NPI first.
If you have a SunOS or Solaris source license, you will find that
even there, the NPI fddi drivers are binary only modules.  (I know,
we have Solaris source license at work.)

As for the wisdom of doing a SMT implementation in the software
driver, as opposed to a firmware implemenation that runs on an
on-the-board processor, well, I'm not going to to go into that.
Certainly the DEC FDDI cards, with their on-board 68000, do all
the SMT processing there, and the OS driver doesn't need to deal with
that at all.  It's good in that if the vendor ships a good SMT,
then everybody who uses the card wins.  If the vendor ships a crappy
SMT, everybody loses.  In this case, it appears that DEC shipped a
pretty good SMT, so everybody wins.

The SMT that NPI ships, of course, has multiple man-years of effort
in it.  I can understand why they don't want to give it away.

All that being said, the NPI cards works really, really well.  I
have a couple of dozen of them deployed in Sparcs running BSD/OS.
(BSDi licensed the NPI driver and ported it to their sparc
port, runs great on Ultrasparc and Hypersparc and Supersparc machines.
I have never tried it on sun4c machines -- not very interesting
hardware.  If you are dying for a reliable BSD system that runs on
sparc hardware, and comes with source for most everything, you should
talk to BSDi.  The *only* binary-only module for the entire sparc tree
is the FDDI driver, naturally.)

-Kurt