Greg KH <greg@xxxxxxxxx> writes: >> 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. As long as these patches get put somewhere for a beating I don't care. They are so cross architecture I'm not really certain where they should sit. >> 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. If we did it I would support them. The important thing is that these patches get put somewhere so other people can build on them. If you don't count msi the changes are pretty trivial. Especially with the last couple of patches removed from the patchset. >> 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 :) I object to genirq going into 2.6.18 without fixing the x86_64 and the x86 regressions I spotted with the number of calls to move_native_irq. x86 calls it twice and x86_64 not at all. But that is a trivial fix. My patchset kills the root case (CONFIG_PCI_MSI non msi irq behavioral changes). Eric - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
