[lkml]   [2006]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/25] Decouple IRQ issues (MSI, i386, x86_64, ia64)
    On Wed, Jun 21, 2006 at 12:24:07PM +0200, Ingo Molnar wrote:
    > * Eric W. Biederman <> wrote:
    > > The following patchset is against 2.6.17-rc6-mm2. It was the only easy
    > > place I could get everyones work who has been touching relevant code.
    > >
    > > The primary aim of this patch is to remove maintenances problems
    > > caused by the irq infrastructure. The two big issues I address are an
    > > artificially small cap on the number of irqs, and that MSI assumes
    > > vector == irq. My primary focus is on x86_64 but I have touched other
    > > architectures where necessary to keep them from breaking.
    > Very nice! Your queue addresses all of the remaining grievances i had
    > about the x86_64/i386 IRQ code (MSI/balancing) and does this ontop of
    > genirq, which is very good. This is much more than i hoped for when you
    > told us about your project! :)
    > The only open bigger issue i guess (besides all the smaller code details
    > that i'm sure we'll sort out) is timing. Your queue, as tempting as it
    > is, is probably not 2.6.18 material. _I_ would certainly dare this for
    > 2.6.18, but Andrew/Linus would kill me i guess.

    No, it needs to sit in -mm for a while. All of the new 2.6.18 stuff
    already has been in there, this is a bit too late for it. I have no
    problem with taking this and letting it get beat on for a few months and
    then go into 2.6.19.

    > So the question is - are we brave/confident enough to try to stabilize
    > this in the next couple of days and drop it into 2.6.18 together with
    > the other bits of genirq?

    No, see above please.

    > I strongly suspect that the bugs this patchset will introduce is
    > roughly equal to the bugs we already have due to the existing MSI and
    > irq-balancing unrobustnesses, so we might as well go for that, instead
    > of prolonging the pain by doing a two-stage (or 3-stage) process.
    > (which would be to introduce genirq stage #1 now, then introduce
    > genirq stage #2 in 2.6.19) Delaying genirq to 2.6.19 altogether would
    > be messy i think and would interfere with ben's (and others') platform
    > plans. Hm?

    I don't object to genirq to go in now for 2.6.18, but this series is too
    new. Incremental changes please :)


    greg k-h
    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: 2006-06-21 18:31    [W:0.035 / U:9.192 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site