Ingo Molnar <[EMAIL PROTECTED]> writes: > * Eric W. Biederman <[EMAIL PROTECTED]> wrote: > >> Ingo would it be reasonable to get a wait queue so I can wait for an >> irq that needs the delayed disable action to actually become masked? > > that might make sense, but what will do the wakeup - incidental IRQ > arriving on the new CPU?
That is what I was thinking. > Isnt that a bit risky - maybe the device wont > generate IRQs for a really long time. Well this is in a user space context called from user space and it exactly matches the semantics we have now. If we make it an interruptible sleep the user space process shouldn't block. I guess the other thing to do is do it in a non-block fashion and just call schedule_work from the interrupt context when the irq is disabled. For i386 with it's in kernel irq scheduler that might be better. I think the nasty case is probably what do we do when it is the timer interrupt we are dealing with. Hmm. I think I should look up what the rules are for calling local_irq_enable when in interrupt context. That might be another way to satisfy this problem. If local irqs are enabled I don't have to worry about the irr register. You've got me brainstorming now. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
