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，但它們應該使用相同的呼叫順序。
在基於堆疊呼叫的體系結構中，上面提到的其他問題可能會導致更大的問題（引數數量不同）。