Re: [PATCH 0/25] Decouple IRQ issues (MSI, i386, x86_64, ia64)

[Greg KH <greg@kroah.com>]

On Wed, Jun 21, 2006 at 12:24:07PM +0200, Ingo Molnar wrote:
> 
> * Eric W. Biederman <ebiederm@xmission.com> 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 :)

thanks,

greg k-h