Path: utzoo!attcan!uunet!husc6!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.microport Subject: Re: Losing interrupts? Message-ID: Date: 3 Oct 88 18:16:02 GMT References: <553@micropen> <1900@van-bc.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 19 To: sl@van-bc.UUCP 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.