> The question is, how should I modify the handler to support sharing > the IRQ? Is it enough to simply always chain to the "downlink" [4] > after processing of my interrupt source is done?
I've found that there is no such thing as an, "If you always do it this way you'll never have any problems" solution. There are just too many ways other programs can work (correctly or incorrectly) which can mess things up. For example, on one of my older computers I had a BIOS that would automatically try to quash spurious IRQs. If the BIOS code ever processed an IRQ request that it thought was wrong, it would issue the EOI to the PIC and then disable the IRQ in the PIC so the IRQ would never be generated again. It was so long ago that I don't remember which IRQs had this "special code", but IIRC it was the COM port IRQs. Anyway, if your program simply always passes down the IRQ processing to the previous handler (which could be the BIOS), you could have serious problems. But, since in modern systems the IRQs can be level-triggered instead of edge-triggered, you can't be 100% sure yours is the only software that needs to get processed by the IRQ so you should always pass the software down to the old handler. I think what I had to do in the program I was working on at the time was to make sure I CALLed the old handler and then on the way back up the software chain I needed to verify that the IRQ was still enabled in the PIC. Another thing I've come to realize that I should never issue a non-specific EOI to the PIC, but instead always issue a specific EOI. Particularly with my USB programs where I am needing to virtualize other hardware and even virtualize IRQs I find this necessary to keep the PIC(s) from getting out of sync with reality. This also brings up the issue of whether to CALL or JMP to the previous handler, and whether to pre-process or post-process (or some combination). I've found it depends on the context of exactly what is supposed to happen when. A lot of it boils down to what needs to happen before the EOI and what can happen afterwards, and where exactly in the software the EOI is generated (usually by the last handler in the chain). Things like IISP can help in certain situations, but almost nobody implements IISP so I've not found it very helpful in processing EOIs (but it is VERY helpful for other things), even though I use AMIS (which includes IISP) myself. _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
