[lkml]   [2007]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] killing the NR_IRQS arrays.
    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.


    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: 2007-02-17 22:19    [W:0.024 / U:0.604 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site