In a properly optimized UNIX system, the kernel spends minimum time (i.e.
minimum instructions) with any or all of the interrupts locked out (what we
used to call spl7() in the old days). The other part of getting a UNIX
system right is the hardware design of the interrupt structure - which
devices have higher or lower priority interrupts, based on how often they
will interrrupt, which require more "real time" response, which ones must
always be serviced above all others (i.e. the clock), etc.

Unfortunately, we are stuck with whatever Apple decided was right for the
Mac hardware running MacOS, not UNIX. From the descriptions of the driver
written here, it sounds like NetBSD is already playing a very old game
called Pseudo-DMA: writing a minimal assembly language routine in locore.s
to suck characters out of the UART chip FIFO and into a kernel ring buffer
as quickly as we get receive interrupts, and then returning from the
interrupt in minimum time, while posting some kind of software interrupt to
call the normal tty handlers while the serial interrupts are not locked out
(or calling the tty handler directly from the asm after interrupt level is
set back to previous state prior to receive interrupt).

If we're still getting UART chip FIFO overflows with this kind of
structure, then there are several possibilities for really fixing it:

1. examine the interrupt handlers for all other higher priority devices
with an eye toward reducing the amount of time they spend handling those
interrupts (i.e. bum instructions out of 'em). Laborious, but rewarding
when you're done.

2. directly calling the serial receive interrupt handler from other
interrupt handlers (and other places that lock out interrupts for "a long
time") in order to make sure that the UART FIFO does not overflow. Oh, did
you say you wanted machine independent code? I'm terribly sorry...

It is my understanding that Apple plays a little bit of #2 so that the
slower 68K Macs can keep up with LocalTalk.

So, where do we start?

Erik Fair