Why is it required to Clear and Unmask an Interrupt?

Background and Justifications Here is a snippet from setvec.c in sparc/erc32: `c if ( SPARC_IS_INTERRUPT_TRAP( vector ) ) { uint32_t source; source = SPARC_INTERRUPT_TRAP_TO_SOURCE( vector ); ERC32_Clear_interrupt( source ); ERC32_Unmask_interrupt( source ); } ` After an ISR is installed for the said vector, methods to Clear and Unmask the "source" are called. If I look into what it actually does, I can summarise it as: - Checking if a particular vector number corresponds to a trap, i.e. interrupts generated via external sources like a timer or peripherals. - If Yes, then convert the trap number to interrupt source ID, i.e. look into the origin of the interrupt. - ERC32_Clear_interrupt(source) tells the origin that the particular interrupt is handled. - While an interrupt is being handled it is often masked, to tell that the interrupt is in the process of handling. ERC32_Unmask_interrupt(source) is used to unmask the source so that if another interrupt occurs, it can be processed again. Since this is a part of the setvec.c file, I refactored it into a helper ERC32_Clear_and_unmask_interrupt() for sparc/erc32 and included it as a separate file. While this can be a general approach for all the BSPs, there is a catch. This Clear and Unmask snippet only found in SPARC BSPs because only they treat external interrupts as traps while others like ARM, x86, or PowerPC have a dedicated Programmable Interrupt Controller(PIC) to handle those. So, A stub would need to include conditional behaviour just for SPARC while providing no logic or value for others. Also, It would introduce unnecessary complexity and clutter in the non-SPARC BSPs: they'd either stub out the code entirely or include unused macros. Conclusion As the way i see it now, I will only be needing the helper function to be implemented in SPARC BSPs and in others there is no requirement for that. Moving forward, I will be working on nios2_iss this week.