Path: utzoo!utgpu!water!watmath!clyde!ima!spdcc!dyer From: dyer@spdcc.COM (Steve Dyer) Newsgroups: comp.unix.microport Subject: Re: Losing interrupts? Message-ID: <1988@spdcc.COM> Date: 5 Oct 88 13:09:22 GMT References: <10770002@hpcupt1.HP.COM> Reply-To: dyer@spdcc.COM (Steve Dyer) Organization: S.P. Dyer Computer Consulting, Cambridge MA Lines: 26 In article <10770002@hpcupt1.HP.COM> vandys@hpcupt1.HP.COM (Andrew Valencia(Seattle)) writes: >>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. > God, here we go again. Listen *very carefully*: >1. Old SCO XENIX was weird >2. Current SCO XENIX is a port of System V >3. Current SCO XENIX is still somewhat weird in the name of compatibility >4. Current SCO XENIX will become less weird when the merged port comes out Well, you're both right. I think Chuck's point is well taken that Microsoft had had a lot more experience on what NOT do to to get decent performance on a PC-type machine. A lot of this is just plain old kernel expertise. If you've ever looked at Sys V.3 kernel sources, you will find spln()'s all over the place, in places where there's no possibility that an interrupt could affect a particular flag or data structure. This is not inherently bad, but is a clue that some of the people who worked on it weren't quite on the ball (now, there's a lot of code which is correct, too!) Add to that the need for an OEM like Microport to provide its own device drivers and this has a greater possibility of occurring (calling the line discipline input routine at spl7(), if it's true, is a good example of this.) -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer