On Wed, 18 Dec 2002, Jun Sun wrote:
> > do_IRQ(poll_8259A_irq(), regs);
>
> I actually don't like the new semantic. The main drawback is that we can't
> dispatch a 8259A interrupt from assemably code, which is often needed.
You can't do that with your original code either, unless you arrange a
call to your dispatch_i8259_irq() C function. This can still be done with
a trivial wrapper like:
asmlinkage void foo_dispatch_i8259_irq(struct pt_regs *regs)
{
do_IRQ(poll_8259A_irq(), regs);
}
which results in code like you proposed.
> What is wrong with original way of dispatching? The general interrupt
> dispatching flow is that you chase the routing path until you find the final
> source and do a do_IRQ(). That seems fine with i8259A case here.
It does too much and is therefore useful for a single specific case only.
I focused on handling the chip only and the resulting function may be used
however desired, including your specific case. Not all platforms need to
want to call do_IRQ() immediately after getting an IRQ number, including
code already in existence.
> While there is certain urge to create asm/i8259a.h file, if in the end all there
> is two function declarations (i8259_init() and dispatch_i8259_irq()), it is not
> really worth it.
The header issue is orthogonal -- for lone init_i8259_irqs() it should
exist. Otherwise you'll be doomed upon the next interface change.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
