Aros/开发者/文档/HIDD/IRQ
convert to KrnAddInterrupt/KrnRemInterrupt, and irq.hidd is deprecated
HIDD API 事实上是重量级的。您需要打开一个 HIDD 库，打开 oop.library，实例化一个对象（即使实际上没有对象，就像在这种情况下）；而对象调用比普通的库调用更昂贵。
- 面向对象的方法有利于实现复杂的事物，因为它提供了代码重用。它被证明对图形和 PCI 代码很有用。但是什么是 IRQ 处理呢？它只是一些列表，仅此而已。您可以添加或删除处理程序，剩下的就超出您的控制范围了。
- 实际上，开发人员不应该与“IRQ 编号”实体进行交互。我们的 PCI API 不完整，因为它缺少“为设备添加中断处理程序”方法。当前方法仅在 PC 类机器上有效，PCI 和系统 IRQ 之间存在一对一的关系。
例如，在 Amiga 上，不存在这种关系。在那里，所有 PCI 设备共享同一个系统中断，需要使用桥接器特定的代码进行解复用。因此，直接 IRQ 处理仅由以下部分需要：
- 底层系统组件，例如 PCI 驱动程序本身。
- 具有硬连线 IRQ 的非自动配置设备（PC 遗留设备）。
但是，这种“开发人员不应该与“IRQ 编号”进行交互”的说法，是否也意味着从第三方开发人员的角度来看 KrnAddIRQHandler 也是错误的呢？该函数是否应该被移动到 pci 设备对象中，并让它与内核进行通信呢？一个合适的 API 将以“事件”或“消息”的形式工作。中断将只是一个实现细节。或者可能是信号-槽范式。有一些文献比较了这两种方法。
让 irq.hidd 成为内核.resource 函数的薄包装器是一件好事，因为它为开发人员提供了一个一致的接口来进行操作 - 始终是 HIDD（irq、pci、图形等）。我不明白这种包装器如何有用，我认为它只会使事情变得更加复杂。
许多地方使用不同的签名调用 struct Interrupt's is_Code。
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..
..以及许多地方，驱动程序使用不同调用签名的函数设置 is_Code，但它们应该使用相同的调用顺序。
在基于堆栈调用的体系结构中，上面提到的其他问题可能会导致更大的问题（参数数量不同）。