Losing interrupts?

[Steve Dyer]

In article <10770002 at hpcupt1.HP.COM> vandys at 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 at harvard.harvard.edu
dyer at spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer