irq.c

irq.c

[Pete Popov]

There's a dozen copies of "irq.c", and a few more files that do the same
thing but are named differently. The irq.c in arch/mips/kernel doesn't
seem to be used by any system.  The PowerPC also has lots of variants
also, but I believe they have a single irq.c file that all systems use. 
So I guess my question is, is anyone using arch/mips/kernel/irq.c, and
does everyone plan on moving to that file (which seems like the right
thing to do).  

Pete

Re: irq.c

[Justin Carlson]

On Fri, 09 Feb 2001, Pete Popov wrote:
> There's a dozen copies of "irq.c", and a few more files that do the same
> thing but are named differently. The irq.c in arch/mips/kernel doesn't
> seem to be used by any system.  The PowerPC also has lots of variants
> also, but I believe they have a single irq.c file that all systems use. 
> So I guess my question is, is anyone using arch/mips/kernel/irq.c, and
> does everyone plan on moving to that file (which seems like the right
> thing to do).  
> 

I've noticed that arch/i386/kernel/irq.c has this note on it:

/*
 * (mostly architecture independent, will move to kernel/irq.c in 2.5.)
 *
 * IRQs are in fact implemented a bit like signal handlers for the kernel.
 * Naturally it's not a 1:1 relation, but there are similarities.
 */

My internal code uses this as a template, in anticipation of this move;
assuming this will happen in 2.5, does it make sense to do an intermediate move
to a common mips/kernel/irq.c?

If it does, I'd like to see mips/kernel/irq.c updated to more closely match the
i386 version, but I'm curious what other people think.

-Justin

Re: irq.c

[Pete Popov]

Justin Carlson wrote:
> 
> On Fri, 09 Feb 2001, Pete Popov wrote:
> > There's a dozen copies of "irq.c", and a few more files that do the same
> > thing but are named differently. The irq.c in arch/mips/kernel doesn't
> > seem to be used by any system.  The PowerPC also has lots of variants
> > also, but I believe they have a single irq.c file that all systems use.
> > So I guess my question is, is anyone using arch/mips/kernel/irq.c, and
> > does everyone plan on moving to that file (which seems like the right
> > thing to do).
> >
> 
> I've noticed that arch/i386/kernel/irq.c has this note on it:
> 
> /*
>  * (mostly architecture independent, will move to kernel/irq.c in 2.5.)
>  *
>  * IRQs are in fact implemented a bit like signal handlers for the kernel.
>  * Naturally it's not a 1:1 relation, but there are similarities.
>  */
> 
> My internal code uses this as a template, in anticipation of this move;
> assuming this will happen in 2.5, does it make sense to do an intermediate move
> to a common mips/kernel/irq.c?
> 
> If it does, I'd like to see mips/kernel/irq.c updated to more closely match the
> i386 version, but I'm curious what other people think.

Thanks for pointing that out.  If all architectures will move to
kernel/irq.c, then it probably makes sense to wait.  At first glance,
mips/kernel/irq.c seems pretty close to i386/kernel/irq.c -- certainly a
lot closer than many of the other copies.  

Pete

Re: irq.c

[Ralf Baechle]

On Fri, Feb 09, 2001 at 11:07:58AM -0800, Pete Popov wrote:

> Thanks for pointing that out.  If all architectures will move to
> kernel/irq.c, then it probably makes sense to wait.  At first glance,
> mips/kernel/irq.c seems pretty close to i386/kernel/irq.c -- certainly a
> lot closer than many of the other copies.  

It was derived from a fairly recent copy of the x86 irq.c; running out of
time I never completed the rewrite.  The idea is to implement some kind
of modular interrupt mechanism which allows us to have a single piece of
code in the MIPS kernel that knows how to handle i8259 interrupt, a single
piece of code to handle GT64120 interrupts etc.  Not like the current mess
which duplicates code ad infinitum.

Aside it's also going to make the RTLinux fraction happy.

  Ralf