Losing interrupts?

Charles Hedrick hedrick at athos.rutgers.edu
Tue Oct 4 04:16:02 AEST 1988


But SCO is based on Xenix.  I don't know how much traditional Xenix
code is present now compared with code from ATT's System V, but at
least the developers had Xenix available to steal from.  So they may
not have had to go through the System V kernel from scratch, "cleaning
up" interrupt handling.  Rather, they may simply have adopted Xenix
methodology for dealing with them.  Xenix was designed from the
beginning for relatively slow machines and support of funny devices,
so it is reasonable to think that it might have better interrupt
latency than SV.  If the problems are in the base SV/286 or 386
kernel, i.e. the part from ATT/Intel, it may not be practical for
Microport to fix it.  I've recently been working on Minix a lot to get
serial I/O to work there.  The fixes were in general not to the RS232
driver, but throughout the kernel to keep down the size of locked code
segments.  Also some adjustment of buffer sizes, again not at the
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.



More information about the Comp.unix.microport mailing list