Losing interrupts?

[Michael Grenier]

>From article <Oct.3.14.16.01.1988.28689 at athos.rutgers.edu>, by hedrick at athos.rutgers.edu (Charles Hedrick):
> driver level.  I would expect something similar in Unix.  Microport
> may be unable/unwilling to make changes throughout the ATT-maintained
> portion of the kernel.  Everybody keeps yelling about the serial
> device drivers as if the problem could be fixed there.  I really doubt
> it.

Actually, I believe the problems with the lost interrupts could be
fixed in the serial device drivers. Right now, as each character forces
an interrupt, the interrupt routine looks at the Interrupt Identification
register and decides if a character is available to be read or not. If
it is, the character is NOT simply put into a buffer but is also
passed though the line discipline routines (clists and stuff) while
running at spl7 (all other interrupts are turned off). This takes
a considerable amount of time and should not be used within an interrupt
routine. You can read a better discussion about clists in real time 
device drivers in the book "Writing UNIX Device Drivers". 

A better solution would be to simply put the character into a buffer 
and return out of the interrupt routine. Then the trick becomes "How
do we get the characters through the line disipline routines?". One
method might be to steal an idea that was presented in the book
"The UNIX Papers" where polling was used in the device drivers. A
working example of this is the Bell Tech's ICC card or Digiboard's
Intelligent card where a seperate process is running handling the 
details of the card. The idea I have is to have a seperate process
waiting on a wait() in the kernel where it would wakeup every
1/60th or 1/30th of a second to read the characters out of the 
buffer and pass them though the line disipline routines. In this
way, most of the character processing time would be handled on
with interrupts turned on. To improve processing time, one could
allow reads and writes in raw mode to be passed directly to the buffers
bypassing the line disipline routines altogether. (This assumes
programs like UUCP and ZMODEM run with the serial line in RAW mode).
I'm no device driver expert but I think the process can be made to 
wait at a priority less than PZERO so it will be the next process to run
every tick or so...we don't want an undue latency time for people
running terminals on the serial lines.

I would be happy to write the above mentioned driver (to include
support for the 16550 UARTS sitting here) if someone could explan
to me what all of the fields in the linesw structure (in sys/conf.h)
and tty structure (in sys/tty.h) are.

    -Mike Grenier
     mike at cimcor.mn.org
     ...uunet!rosevax!cimcor!mike
     ...amdahl!bungia!cimcor!mike