Interrupt Handling Issues

[RezaNoei]

Hi,

I have some question about interrupts and more about how to taking a correct approach in facing with them.
in some tutorials that i have read; there was two different strategy in interrupt handling:
1. Creating a generic interrupt handler :
in this case we have a wrapper function (in asm) that will pushes the interrupt number to the stack and will calls a single interrupt handler,
this single interrupt handler will knows the interrupt number, that is currently fired.
so it must handle the situation through this number (and sometimes with an error code).
i think this way makes a lot of code that we must put in a single function, the result will be a large
and complex function that will make our progresses slower than normal.
2. Creating an interrupt handler for each interrupt number
in this way we must classify each type of interrupt (for example, 1: CPU interrupts, 2: software interrupts, 3: external interrupts)
we can define some special handler to handling only the CPU's interrupts (interrupt 0-19), and taking
above approach in facing with two other class of interrupts (software and external interrupts)
if i said right, can you help me for choosing a way that could help me in later developments.
if i had some mistakes please help me to find out it.

another question that i have is about returning from interrupt handlers.
so we have a wrapper that will saves the registers and segment descriptors and then, this wrapper calls
our high-level handler, finally this wrapper just restores those values and then executes an IRET instruction.
in this process as expected after running our interrupt handler we must return to previous code that was in running state, or in the other
think the process that earns the running chance in our task scheduling process.
so, is this true ? or needs to be corrected.

the other issue is about nested interrupts. can we able to accept nested interrupts in this two ways, either by playing with sending
interrupt done signal to PIC or some other ways ? as i checked in my project nested interrupts are ignored.
so, where is the solution ?

thank you all.

[SpyderTL]

You are on the right track. I actually do both: I have individual interrupt handlers for different types of interrupts, and those handlers call a common interrupt handler that increments a counter in a 255 byte array.

You will just need to be able to notify your device drivers when an interrupt happens -- ideally notifying only the drivers that are "listening" to that particular interrupt.

When switching threads, you pretty much just need to swap out the SP register while you are in your interrupt handler, and then call IRET. The new thread stack will have the return address sitting on the top. Eventually, you'll need to store a few more thread details, like paging tables and extended registers, but for now, you should be fine just storing the thread stack.

You shouldn't be getting nested hardware IRQ interrupts if you are using the PIC properly, but you can get CPU interrupts inside your interrupt handlers. But those should only happen if you have a bug in your handler, or don't have your paging tables set up properly.