Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!eos!labrea!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: PS/2 level-triggered interrupts
Message-ID: <1984@ast.cs.vu.nl>
Date: 29 Jan 89 22:29:57 GMT
References: <1907@ast.cs.vu.nl> <11932@dartvax.Dartmouth.EDU> <1974@ast.cs.vu.nl> <12009@dartvax.Dartmouth.EDU>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 26

In article <12009@dartvax.Dartmouth.EDU> stevel@eleazar.dartmouth.edu (Steve Ligett) writes:
>2.  Mask interrupts in the 8259.  That's what Steve Ackerman has
>working, I believe.  The problem with that is that you've now thrown
>away the reason for level-sensitive interrupts, and I thought it was too
>early in the game to give them up.

That is also the solution I proposed a couple of days ago.  I don't think
it defeats the purpose of level-triggered interrupts.  Its purpose is to
get around the fact that there aren't enough interrupt lines.  By masking out
interrupt 14 until the floppy disk task runs, it is true that you inhibit
interrupts by any other device on that line.  However, when the floppy disk
task runs and senses the FDC and sends the EOI, the other device will then
generate its interrupt.  I don't think anything is lost.

The solution proposed by Steve Ligett, which is also what Adrie Koolen did,
has the disadvantage of requiring the interrupt routine to do whatever magic
thing is needed to cause it to negate the interrupt.  For the floppy it is
a sense.  Heaven knows what it is for an Ethernet board or a laser printer.
I prefer not to have a lot of device specific code in the interrupt handlers
if possible.  Another point is that for some devices it may take a fair
amount of work to make the thing shut up, which means running for a long
time with interrupts disabled.

More discussion on the pros and cons of the various methods is welcome.

Andy Tanenbaum (ast@cs.vu.nl)