On 5/24/06, Erik Scharwaechter <diozaka@xxxxxx> wrote:
Hello, in some situations, the Linux kernel may disable interrupts using local_irq_disable(). On x86 systems this is implemented with the CLI assembly instruction, which sets the CPU's IF flag to 0. The IA32 System Programming Guide says about clearing the IF flag: > When the IF flag is clear, the processor inhibits interrupts delivered to > the INTR pin or through the local APIC from generating an internal > interrupt request. As far as I understand this passage, interrupts delivered to the processor are disposed and not put into some kind of internal queue. What if an important interrupt, i.e. an interrupt that has to be handled as soon as possible, is sent to the processor while the IF flag is set to 0? The kernel will never notice this event, unless the interrupt is resent again later by the device. Is this correct?
True.
Wouldn't it be more efficient to add the missed interrupts to a queue to deal with it as soon as interrupts have been enabled again?
I dont have an exact idea, what happens internally. But these interrupts are time realted events and handling it sometimes later, doesnt makes sense. It would be something like " Placing an order for the food that you want to eat after two days ". And also on an x86 machine there are privilage levels, so only privilaged users can disable intrrupts, So, that means that you want to disable the interrupts completely. -- Regards, Sandeep Winners expect to win in advance. Life is a self-fulfilling prophecy. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
