Navbar for the Aros wikibook
Aros User
Aros User Docs
Aros User FAQs
Aros User Applications
Aros User DOS Shell
Aros Dev Docs
Aros Developer Docs
Porting Software from AmigaOS/SDL
For Zune Beginners
Zune .MUI Classes
For SDL Beginners
Aros Developer BuildSystem
Specific platforms
Aros x86 Complete System HCL
Aros x86 Audio/Video Support
Aros x86 Network Support
Aros Intel AMD x86 Installing
Aros Storage Support IDE SATA etc
Aros Poseidon USB Support
x86-64 Support
Motorola 68k Amiga Support
Linux and FreeBSD Support
Windows Mingw and MacOSX Support
Android Support
Arm Raspberry Pi Support
PPC Power Architecture
Aros Public License
convert to KrnAddInterrupt/KrnRemInterrupt, and irq.hidd is deprecated



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.



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:

   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).