LKML Archive on
help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <>
To: "Eric W. Biederman" <>
Cc: Arnd Bergmann <>,
	Russell King <>,,,
	Linus Torvalds <>,
	Andrew Morton <>,
	Andi Kleen <>, Ingo Molnar <>,
	Alan Cox <>
Subject: Re: [RFC] killing the NR_IRQS arrays.
Date: Sun, 18 Feb 2007 08:15:49 +1100	[thread overview]
Message-ID: <1171746949.5644.137.camel@localhost.localdomain> (raw)
In-Reply-To: <>

On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <> writes:
> > In addition, if we remove the numbers, archs will need basically the
> > exact same services provided by the powerpc irq core for reverse mapping
> > (going from a HW irq number on a given PIC back to an irq_desc *).
> Ben you seem to be under misapprehension that except for the case of
> ISA (0-16) the linux IRQ number is a hardware number.  It is an arbitrary
> software enumeration, and I think it has been that way a very long time.

Did you actually mean "is not a hardware number" ? If not, then I don't
understand your sentence...

> I can only tell you that my impression of this last is that all the
> world's not a PPC.

Yeah and my grandmother is not the pope, thank you.

However, PowerPC is a good example because it has such a diversity of
very different hardware setups to deal with, ranging from the multiple
layers of cascading controllers all over the place, to interrupts
packets encoding vector/target etc... a bit like x86 on cell, to
hypervisors providing a single giant number space etc etc etc...

Thus, it is extremely likely that something that works well for PowerPC
(or for ARM for that matter as it's probably as a "colorful" environment
as PowerPC is) will end up being useful for others.

> I have a version of the x86 code with a partial conversion done and
> I didn't need a reverse mapping.  What you call the hardware interrupt
> number never happens to be interesting to me after the system is setup.

Because you have the ability to tell your PIC to give you your "linux"
interrupt number when actually sending the interrupt to the processor ?
You need a way to get to the irq_desc * when getting an IRQ, either you
have a way to map HW numbers back to irq_desc * in sofrware, or your HW
allows you to do it.

> I do suspect there may be an interesting chunk of your ppc work that
> probably makes sense as a library so other arches could use it.

Guess what, one of the options of my code is to not instanciate a
remapper... for archs where it's not necessary. (We have the case for
example of iSeries whose hypervisor can return us the number we want for
an arbitrary interrupt).

Now, I'm not saying we should take the PowerPC code and say "hey' here's
the new generic code".

I'm saying that if we're going to change the IRQ stuff that deeply, it
would be nice if we looked into some of that stuff I've done that I
beleive would be of use for other archs (though you seem to imply that
it would be of no use on x86, good, still...).

I found it overall very useful to have a generic remapping core and have
cascaded PIC setups have a numbering domain local to a given PIC (pretty
much, a domain != an irq_chip) and I'm convinced it would make life
easier for archs with similar setups. The remapping core also shows its
usefulness on archs with very big interrupt numbers, like sparc or
pSeries ppc, and possibly others.

Now, I -do- have a problem with one aspect of your proposed design which
is to keep the "linux" interrupt number in the generic irq_desc, which I
think defeats most of the purpose of moving away from those linux irq
numbers. If you do so, then I'll have to keep a separate remapping layer
and keep a mecanism for virtualizing linux numbers.


  reply	other threads:[~2007-02-17 21:16 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16 12:10 [RFC] killing the NR_IRQS arrays Eric W. Biederman
2007-02-16 12:16 ` Andi Kleen
2007-02-16 15:35   ` Eric W. Biederman
2007-02-16 12:41 ` Ingo Molnar
2007-02-16 15:23   ` Eric W. Biederman
2007-02-16 15:49   ` Eric W. Biederman
2007-02-16 22:33   ` Benjamin Herrenschmidt
2007-02-18 21:24   ` Arjan van de Ven
2007-02-19  0:25     ` Benjamin Herrenschmidt
2007-02-27 20:29       ` Eric W. Biederman
2007-02-28  0:41         ` Arnd Bergmann
2007-02-28  7:20           ` Eric W. Biederman
2007-02-28  8:09             ` Benjamin Herrenschmidt
2007-02-28 13:28               ` Eric W. Biederman
2007-02-28 12:24             ` Arnd Bergmann
2007-02-28 13:02               ` Segher Boessenkool
2007-02-28 13:53               ` Eric W. Biederman
2007-03-01 10:47                 ` Benjamin Herrenschmidt
2007-02-16 18:07 ` Jeremy Fitzhardinge
2007-02-16 19:01   ` Eric W. Biederman
2007-02-16 19:06     ` Jeremy Fitzhardinge
2007-02-16 19:45 ` Arnd Bergmann
2007-02-16 19:52   ` Russell King
2007-02-16 20:43     ` Arnd Bergmann
2007-02-16 20:59       ` Russell King
2007-02-16 22:37     ` Benjamin Herrenschmidt
2007-02-17  1:37       ` Arnd Bergmann
2007-02-17  4:00         ` Benjamin Herrenschmidt
2007-02-17  9:06           ` Eric W. Biederman
2007-02-17 21:15             ` Benjamin Herrenschmidt [this message]
2007-02-18  6:30               ` Eric W. Biederman
2007-02-18 20:01                 ` Benjamin Herrenschmidt
2007-02-17  9:34     ` Eric W. Biederman
2007-02-17 21:20       ` Benjamin Herrenschmidt
2007-02-18  3:58         ` Eric W. Biederman
2007-02-16 22:29 ` Benjamin Herrenschmidt
2007-02-17  8:51   ` Eric W. Biederman
2007-02-17 21:04     ` Benjamin Herrenschmidt
2007-02-18  4:58       ` Eric W. Biederman
2007-02-18 19:58         ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1171746949.5644.137.camel@localhost.localdomain \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).