[lkml]   [2001]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Question about IRQ_PENDING/IRQ_REPLAY
In article <>,
Cort Dougan <> wrote:
>More generic in terms of using irq_desc[] and some similar structures I can
>see. Making do_IRQ() and enable/disable use the same names and structures
>as x86 isn't sensible. They're different ports, with different design
>I don't believe that the plan is a common irq.c - lets stay away from that.

Most of arch/i386/kernel/irq.c should really be fairly generic, and the
fact is that a lot of the issues are a lot more subtle than most people
really end up realizing. I got really tired of seeing the same old SMP
problems that had long since been fixed on x86 show up on other

So the plan is to have at least a framework for allowing other
architectures to use a common irq.c if they want to. Probably not force
it down peoples throats, because this is an area where the differences
can be _so_ large that it might not be worth it for everybody. But I
seriously doubt that PPC is all that different.

And I seriously doubt that PPC SMP irq handling has gotten _nearly_ the
amount of testing and hard work that the x86 counterpart has. Things
like support for CPU affinity, per-irq spinlocks, etc etc.

Now, I'm not saying that irq.c would necessarily work as-is. It probably
doesn't support all the things that other architectures might need (but
with three completely different irq controllers on just standard PCs
alone, I bet it supports most of it), and I know ia64 wants to extend it
to be more spread out over different CPU's, but most of the high-level
stuff probably _can_ and should be fairly common.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:29    [W:0.069 / U:0.988 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site