Path: utzoo!attcan!uunet!munnari!basser!steve
From: steve@basser.oz (Stephen Russell)
Newsgroups: comp.os.minix
Subject: Re: PS/2 level-triggered interrupts
Message-ID: <1727@basser.oz>
Date: 25 Jan 89 14:36:01 GMT
References: <1907@ast.cs.vu.nl> <11932@dartvax.Dartmouth.EDU>
Organization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 46

In article <11932@dartvax.Dartmouth.EDU> stevel@eleazar.dartmouth.edu (Steve Ligett) writes:
>I think the best way of fixing the interrupt problem for floppy disks is
>to call fdc_results within disk_int and return the status bytes in the
>message.
> [ rest deleted ]

Although this may fix the floppy driver, it becomes real messy when
adding drivers for mice, network boards, hi-res graphics, et.al. If
the problem is that the _drivers_ are the only code that can reset the
interrupting device properly, then the only solution seems to be to abandon
the "all interrupts go through one place" strategy. One (reasonably) clean
solution may be something like this:

- Use a common interrupt handler only for the purposes of saving the
registers. The common handler then does an indirect call through a local
table of interrupt handler addresses. This assumes that the common handler
has some _quick_ way to identify the source of the interrupt (the 8259?).

- Device drivers "register" a handler at start-up for their interrupt
number. The private handler looks after reading the status, etc, clears
the interrupt request, re-enables interrupts (which have been disabled long
enough by now), and returns to the common handler, which sends the message
to the driver task.

- Until a handler is registered, the call table contains the address of
a panic routine. This is probably a bit drastic - can the interrupt just
be ignored, at least initially?

- Where do the private handlers save the device status? I guess static
storage in the driver code would be fine, so long as there are no overruns.
These are only likely for keyboard and RS232 input - the rest of the
devices won't interrupt again until given something to do by the driver
task. Drivers that experience overruns could disable the device input interrupt
until the task is activated. Incrementing a counter each time the interrupt
handler is called, which is reset by the task, allows overruns to be detected.

The advantage of this approach is that the device interrupt handling
logic is where it should be: in the code for each device driver, not in
the interrupt handler.  If the cost of the indirect call is too much
extra burden, then we are stuck with lots of little bits of assembler
for each device, which are triggered directly by the interrupt. This
maximises speed, at the cost of duplication of effort among the
drivers.

[It's been a while since I looked at Minix. If lots has changed since
1.1, and the above comments are a heap of noise, my apologies.]