Aros/Developer/Docs/HIDD/IRQ
convert to KrnAddInterrupt/KrnRemInterrupt, and irq.hidd is deprecated
Introduction
[edit | edit source]HIDD API is, in fact, heavyweight. You need to open a HIDD library, open oop.library, instantiate an object (even if there's no object in fact, like in this case); and object calls are more costly then plain library calls.
- Object-oriented approach is good for implementing complex things, because it provides code reuse. It's proven to be nice for graphics and PCI code. But what is IRQ handling? It's just lists, nothing more. You either add or remove handlers, the rest is out of your control.
- In fact the developer should not interact with "IRQ number" entity at all. Our PCI API is incomplete, because it lacks "Add interrupt handler for the device" method. Current approach works only on PC-alike machines, with 1:1 relationship of PCI and system IRQs.
For example, on Amiga there's no such relationship. There all PCI devices share the same system interrupt, which needs to be de-multiplexed using bridge-specific code. Consequently, direct IRQ handling is needed only by:
- lowlevel system components, like PCI driver itself.
- Non-autoconfigurable devices with hardwired IRQs (PC legacy devices).
But doesn't this 'developer should not interact with "IRQ number"' make the KrnAddIRQHandler also wrong from 3rd party developers point of view? Shouldn't the function be moved to pci device object and have it talk with kernel? A proper API would work in terms of "events" or "messages". Interrupts would just be an implementation detail. Or perhaps a signals-slots paradigm. There's some literature out there that compares the two approaches.
References
[edit | edit source]Having irq.hidd a thin wrapper over kernel.resource functions is a good think because it gives developers a cohesive interface to work against - always HIDD (irq, pci, graphics, etc). Don't see how such a wrapper can be useful, IMHO it only over complicates things.
many places where struct Interrupt's is_Code is being called with different signatures:
rom/exec/intservers.c: IntServer expects intMask in D0 (instead of the correct D1) .. but calls is_Code without D1 Interrupt Server: D0/D1 = undefined. Handler: D0 undefined, D1 = mask. VBlankServer expects intMask in D1 .. and calls IntServer with it in D1. SoftIntDispatch expects 5 arguments... .. but calls the chained interrupt with only 3..
.. and numerous places where drivers are setting up is_Code with functions with different calling signatures but they _should_ be called with the same calling sequence.
On stack-call architectures, the other problems mentioned may lead to bigger issues (different # of arguments).