@H_403_2@I most recently worked very closely with Linux interrupts on a particular MIPS architecture. On that particular board,there were 128 interrupt lines maskable via two 64 bit words. The kernel implemented a priority scheme on top of this,so before executing a handler for a given interrupt,the lower ones were masked via updates of those 2×64 bit registers. I implemented a modification so that the interrupt priorities could be set arbitrarily,rather than by hardware position,and dynamically by writing values into a /proc entry. Moreover,I put in a hack whereby a portion of the numeric IRQ priority overlapped with real-time priority of tasks. So RT tasks (i.e. user space threads) assigned to certain range of priority levels were able to implicitly suppress a certain range of interrupts while running. This was very useful in preventing badly-behaved interrupts from interfering with critical tasks (for instance,an interrupt service routine in the IDE driver code used for the compact flash,which executes busy loops due to a badly designed hardware interface,causing flash writes to become the de-facto highest priority activity in the system.) So anyway,IRQ masking behavior isn’t written in stone,if you’re in control of the kernel used by customers.