public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [i386, x86-64] ioapic_register_intr() and assign_irq_vector() questions
@ 2006-04-13 13:50 Jan Beulich
  2006-04-13 17:11 ` Andi Kleen
  0 siblings, 1 reply; 3+ messages in thread
From: Jan Beulich @ 2006-04-13 13:50 UTC (permalink / raw)
  To: linux-kernel, discuss

Since ioapic_register_intr() ties, for the PCI case, the interrupt gate for vector to interrupt[vector], doesn't this,
since do_IRQ() derives the IRQ from the value loaded in the handler at that address (which is the value of vector), mean
that here irq == vector in all cases? If so, why does this function need an if/else (the 'else' case would then be good
for both cases)?

Looking at the call paths assign_irq_vector() can get called from, I would think this function, namely as it's using
static variables, lacks synchronization - is there any (hidden) reason this is not needed here?

Thanks, Jan

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [i386, x86-64] ioapic_register_intr() and assign_irq_vector() questions
  2006-04-13 13:50 [i386, x86-64] ioapic_register_intr() and assign_irq_vector() questions Jan Beulich
@ 2006-04-13 17:11 ` Andi Kleen
  0 siblings, 0 replies; 3+ messages in thread
From: Andi Kleen @ 2006-04-13 17:11 UTC (permalink / raw)
  To: Jan Beulich; +Cc: linux-kernel, discuss, tom.l.nguyen

"Jan Beulich" <jbeulich@novell.com> writes:

> Since ioapic_register_intr() ties, for the PCI case, the interrupt
> gate for vector to interrupt[vector], doesn't this, since do_IRQ()
> derives the IRQ from the value loaded in the handler at that address
> (which is the value of vector), mean that here irq == vector in all
> cases? If so, why does this function need an if/else (the 'else'
> case would then be good for both cases)?

Yes agreed. irq should be always equal vector. IIRC this 
stems from the MSI work from Tom Nguyen. Maybe he knows
why he coded it like this. I suppose it could be cleaned up.

> 
> Looking at the call paths assign_irq_vector() can get called from, I
> would think this function, namely as it's using static variables,
> lacks synchronization - is there any (hidden) reason this is not
> needed here?

It is only called during system initialization which is single threaded. 
If someone added ioapic hotplug they would need to do something about 
this.

-Andi

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [i386, x86-64] ioapic_register_intr() and assign_irq_vector() questions
@ 2006-04-14 17:16 Jan Beulich
  0 siblings, 0 replies; 3+ messages in thread
From: Jan Beulich @ 2006-04-14 17:16 UTC (permalink / raw)
  To: Andreas Kleen; +Cc: tom.l.nguyen, linux-kernel, discuss

>> Looking at the call paths assign_irq_vector() can get called from, I
>> would think this function, namely as it's using static variables,
>> lacks synchronization - is there any (hidden) reason this is not
>> needed here?

>It is only called during system initialization which is single threaded. 
>If someone added ioapic hotplug they would need to do something about 
>this.

Hmm, as I looked through this I expected this to be possibly called also later, as it seems to be on paths reachable
from exported functions (which clearly can be called only after the single-threaded phase is over.

Jan

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-04-14 17:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-13 13:50 [i386, x86-64] ioapic_register_intr() and assign_irq_vector() questions Jan Beulich
2006-04-13 17:11 ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2006-04-14 17:16 Jan Beulich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox