Re: [Xen-devel] [rfc][patch] use of IRQ_LEVEL to remove strcmp()s

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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