Messages in this thread | | | Date | Thu, 9 Oct 2003 11:03:14 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [RFC] disable_irq()/enable_irq() semantics and ide-probe.c |
| |
On Thu, 9 Oct 2003 viro@parcelfarce.linux.theplanet.co.uk wrote: > > a) on x86: > static void end_8259A_irq (unsigned int irq) > { > if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS)) && > irq_desc[irq].action) > enable_8259A_irq(irq); > }
This matches the "if IRQ is disabled for whatever reason" test in irq.c, and as such it makes some amount of sense. However, from a logical standpoint it is indeed not very sensible. It's hard to see why the code does what it does.
> b) if we get *two* interrupts while irq is enabled and not registered, we'll > be stuck with IRQ_PENDING in addition to IRQ_INPROGRESS. Which can, AFAICS, > confuse other code.
This should not happen: the first one will shut up the interrupt. That's in fact what (a) does - it refuses to enable the interrupt again (and it will have been shut up by the "ack".
(Other interrupt controllers _can_ get multiple interrupts while disabled, like the APIC edge-triggered case. But they have different logic to take care of this - see io_apic.c and the logic there in the [ack|end]_edge_ioapic_irq).
In short, this is all behaviour that depends on the low-level irq controller. It may not be very obvious what is going on, but I think it is correct (and again, it might be worth cleaning up some day. Not now)
> c) mind-boggling amount of code duplication - are there any plans to take > that stuff to kernel/*?
Yes. It was actually tried a few months ago, but some of the other architectures have very different interrupt setups, so it got dropped. But it will almost certainly happen eventually: we've had bugs fixed on x86 that ended up living a lot longer on other architectures.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |