Linux, as of 2.5, supports disabling/enabling : 1. a particular interrupt on a particular processor, or 2. a particular interrupt on all system processors, or 3. all interrupts on a particular processor As of 2.5, disabling all interrupts on all processors is removed. Previous versions did this using cli() and sti() calls. Choosing what to disable (in the above 3 steps) is very specific to a particular interrupt handler (and of course, process context also sometimes disables interrupts, again to synchronize data). Yes, the main purpose of disabling interrupts is to avoid reentrancy of same interrupt handler and synchronization of shared data. Note that there is no need to protect code. Data needs protection. Linux support very primitive interrupt prioritization. Actual prioritization can be achieved by disabling few interrupts, but not all. That way an interrupt X gives priority for other interrupts to preempt while in its own interrupt handler. This is not done right now. The masking is either all or one interrupt. Yes, by disabling an interrupt, interrupt controller or processor doesn't invoke kernel IRQ for that interrupt. The main job is performed by interrupt controller and not the processor. But, that interrupt is not lost. Once an interrupt is enabled, kernel gets the IRQ. Hope this answers all your questions. Read Linux Kernel Development by Robert Love. Venkata. -> I'm reading Understanding the Linux Kernel, and I'm trying -> to understand -> interrupts and exceptions properly. I wonder if I have -> understanded this -> correctly, this is how I think it works, and I would -> appreciate if someone -> could confirm that its right. -> -> So, is this correct? -> -> Linux's interrupts are interleaved, ie. they can be nested. -> That must mean -> that interrupts are enabled when handling interrupts. Now -> the thing that -> confuses me a little is that Linux uses interrupt gates, -> which clears the -> IF flag, and disables interrupts. But it seems like Linux -> sets the IF flag -> again before the actual handler. Is this to protect the code -> before the -> handler from being interrupted? If so, why is this neccesary? -> -> When interrupts are disabled by masking the maskable -> interrupts, does that -> mean that the CPU ignores the signal on the INTR pin. And -> when a IRQ is -> masked on the PIC, does that mean that the PIC doesn't send -> any interrupt -> to the CPU when that IRQ is raised? -> In other words, the IF flag makes the CPU ignore all -> maskable interrupts, -> while masking a particular IRQ, it prevents the interrupt -> from reaching -> the CPU. -> -> When executing an interrupt handler, maskable interrupts are -> enabled but -> the IRQ of the interrupt is masked out. Other interrupts may -> interrupt the -> execution, but not the same as the one currently executed? -> -> Thank you! -> -> /Michael -> -> -- -> Kernelnewbies: Help each other learn about the Linux kernel. -> Archive: http://mail.nl.linux.org/kernelnewbies/ -> FAQ: http://kernelnewbies.org/faq/ -> -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
