|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [rfc][patch] use of IRQ_LEVEL to remove strcmp()s
On 19 Apr 2006, at 21:58, Jimi Xenidis wrote:
Ok this is blind, but it builds, so please take it more as a
suggestion,
There are a sequence of strcmp()s in irq.c to detect if an IO-APIC is
level or edge triggered.
Perhaps (borrowing form Linux) with the use of IRQ_LEVEL, we can
detect this more efficiently?
Given the set of hw_interrupt_types we support right now this
generalised logic appears to work, but in fact we really are testing
for a specific PIC configuration here. For example, if we added a new
hw_interrupt_type that was also level-triggered but which could be
masked quickly and cleanly then it would have ACKTYPE_UNMASK not
ACKTYPE_EOI. So the generalisation you are suggesting (to check for
IRQ_LEVEL) doesn't really work.
The strcmps aren't really a problem -- they're not on a critical path,
and we explicitly bug if we do not match on any of them so we should be
resilient to addition of new PIC types or renamings of existing PIC
types. I think the current code has the additional benefit of
'obviousness'.
Side Note: I believe that "ioapic_ack_new" is the same as IRQ_PER_CPU.
Xen/x86 does not use IRQ_PER_CPU at all. ioapic_ack_new simply
determines whether we handle level-triggered IO-APIC interrupts by
mask-eoi-process-unmask or by process-eoi. The new method is the latter
because it turns out that many IO-APICs do not mask cleanly (they
create spurious aliased interrupts).
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|