Subject: Re: i want FDDI
To: wonko@tmok.com, Al Snell <alaric@alaric-snell.com>
From: Kurt J. Lidl <lidl@pix.net>
List: port-sparc
Date: 02/07/2001 17:03:27
On Wed, Feb 07, 2001 at 04:03:20PM -0500, Brian Hechinger wrote:
> Al Snell drunkenly mumbled...
> > 
> > Hum... it's good to do much of this stuff in userland. Look at the IPv6
> > rtadvd and so on...
> 
> actually i wasn't talking kernel vs userland, i was asking about
> hardware versus software.  are there any advantages to not having
> done ring negotiation in hardware (firmware?)

It's all software.  It's just a question of where the software runs.

1) Does it run on a microcontroller (or embedded CPU) on the card?

2) Does it run as a part of the device driver inside the kernel?

3) Does it run as a userland program?

The various FDDI cards out there in the world that I've ever seen
generally choose #1 or #2.

I don't know of any manufacturer that choose #3, for pretty obvious reasons.
It could be really bad, if your fddi attached diskless workstation
had the SMT daemon paged out.  Then the FDDI ring reconfigured,
and oops! you don't have the daemon in memory to reconfigure the
FDDI ring, so you can get the daemon back!  Your workstation is
hung, waiting for a daemon that can never be paged in to run.

For the cards in question, the NPI manufactured SBUS FDDI cards, I don't
think that #1 is an option -- they don't have a seperate programmable
microcontroller or on-board CPU.  They just have a scatter-gather DMA
engine.  So, you are stuck doing #2 or #3.  Certainly the NPI driver
does #2, both for SunOS and for Solaris 2.X.  The BSD/OS port of
the SunOS driver does #2.

The DEC manufacturered PCI (and EISA) FDDI cards that are supported
by the *BSD and BSD/OS operating systems are of type #1.  There is
a 68000 CPU onboard that runs the SMT software, so the device driver
for the OS never has to worry about it.  Matt Thomas, when he wrote
the FDDI driver that all the *BSD groups ultimately based their
driver on, had a comment about it -- DEC didn't want to rely on
every OS driver (NT, 95/98, SCO, *BSD, etc) to have to get the SMT
portion of the software correct.  DEC had to get it right once,
and then blow it into the ROM on the cards.  Nobody else every had
to worry about getting it right.

-Kurt