Re: [PATCH 00/13] convert voyager over to the x86 quirks model

[Ingo Molnar <mingo@elte.hu>]

* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Tue, 2009-03-10 at 23:37 +0100, Ingo Molnar wrote: 
> > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > 
> > > Given the lack of feedback, I went ahead and implemented the 
> > > additions to smp_ops and x86_quirks (and a dynamic mca NMI 
> > > hook) to allow voyager to be plumbed in.
> > > 
> > > There also needs to be changes in the boot setup to make 
> > > voyager work dynamically: It has to be detected first, so the 
> > > a20 gate check is only executed if a voyager is not found.
> > > 
> > > I also completed some of the subarchitecture eliminations, so 
> > > all the include file infrastructure should be gone.
> > > 
> > > The result is that I can boot both my PC SMP x86 boxes and 
> > > voyager with the same kernel.
> > > 
> > > This patch series applies on the x86/apic branch of the x86 
> > > tree (obviously with 965c7ecaf2e2b083d711a01ab33735a4bdeee1a4 
> > > reverted)
> > 
> > The question is, why would we want to merge Voyager back ever 
> > again?
> 
> What do you mean merge back?  It's an existing and supported 
> architecture in git head.

That's revisionist history that ignores a few inconvenient 
facts. The x86/Voyager subarch last built successfully in 
v2.6.26.0 - in the summer of last year (!):

  v2.6.27.0:   Voyager was broken - it did not even build.
  v2.6.28.0:   Voyager was broken - it did not even build.
  v2.6.29-rc5: Voyager was broken - it did not even build.

... then we removed it from the x86 development tree and 
mentioned that it did not even build for a long time, and Cc:-ed 
you to all that. A few days later you finally sent a fix patch 
for mainline.

We merged that fix into -rc6 as it was small so yes, technically 
'git head works now', but that ignores the long negative track 
record of that code that we as x86 maintainers have experienced.

I.e. by all means it was broken code for almost 3 full kernel 
cycles, up until the very last minute when you saw us removing 
it. Talking about any sort of 'downstream community' and 
'supported architecture' is mocking these terms.

With regards to v2.6.30 it's simply too late - at least as far 
as my schedule goes. v2.6.29-final is maybe a week or two away, 
the merge window is very crowded already and we've pretty much 
closed down APIC related changes already.

You can still try to convince Thomas or Peter (i'm not the only 
x86 maintainer so merge decisions do not depend on me alone and 
you can convince them if you disagree with my position - they 
have symmetric commit rights to the x86 devel tree), but as far 
as i'm concerned personally, this merge window is too tight 
already.

In any case, if you find that code useful feel free to maintain 
it in a separate git tree (where any interested people/users can 
access it easily) and we can revisit this issue in the next 
development cycle, in 2-3 weeks or so, after the merge window.

Thanks,

	Ingo