> > On Wed, 29 Jul 1998 21:34:51 -0700 
> >  Parag Patel <parag@cgt.com> wrote:
> > 
> >  > It's pretty slow because OpenFirmware is designed around a polling-only
> >  > driver architecture but it can be (and has been) done.  Most FCode
> >  > drivers are fairly dumb as they cannot rely on interrupts which are
> >  > system dependent, and OF doesn't specify how to deal with them.
> > 
> > Indeed; running OpenFirmware drivers only on my Shark is VERY SLOW :-)
> 
> I believe that this is implementation, not architecture. Mitch? Care
> to comment? I seem to recall a fairly zippy multitasking environment
> you had set up at one time..

It's a bit of both.  It's true that OFW drivers are polled, not interrupt-
driven (both for reliability and to eliminate the need to share interrupts
between the FW and the OS, which would require more cooperation from the OS
that is often feasible, especially for OSs that don't have the wealth of
system programming talent that is available for NetBSD).

It's also true that using the OFW Ethernet driver on Shark is VERY SLOW.
Howver, it should be possible to improve it rather dramatically, simply
by using an adaptive polling interval based on the amount of recent traffic.
The current implementation just polls on the Unix timer tick, which
happens quite a bit less frequently than is desireable for this use.
The changes to do this would have to be in NetBSD; the firmware part of the
driver is plenty fast, assuming that you poll it frequently enough.
The reason we didn't bother to tune the performance of this is because
the use of the OFW driver was a stopgap measure pending the availability
of the native OS driver.

Mitch