Date:	Wed, 15 Apr 2009 17:35:11 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH 00/14] convert voyager over to the x86 quirks model


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

> On Tue, 2009-04-14 at 20:08 +0200, Ingo Molnar wrote: 
> > * Ingo Molnar <mingo@...e.hu> wrote:
> > 
> > > 
> > > * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > > 
> > > >  39 files changed, 554 insertions(+), 726 deletions(-)
> > > 
> > > That diffstat is not against current mainline, is it? 
> > > Would you mind to send a proper diffstat with the revert 
> > > included as well? That will give us a complete picture.
> > 
> > ok, i did the calculations, and the effect of adding back 
> > x86/Voyager is roughly:
> > 
> >    48 files changed, 5226 insertions(+), 142 deletions(-)
> > 
> > That's quite a lot, and lets put this into perspective.
> 
> Hardly ... you're conflating two issues: one is what is the burden 
> to mainline, which the patch series is about, although only patch 
> 1 (and possibly patch 5) is truly critical to that, the rest are 
> assorted code moves.

This is roughly the diffstat we get when we add x86/Voyager support 
again. Are you saying that the diffstat is wrong? Could you paste 
the right diffstat then (which i asked you to do before, and which 
you have not done), which i'd get if i pulled your tree, if you 
think this one is wrong?

> > You are talking about moving ~5000 lines of legacy code back 
> > into arch/x86/, for a total of *four* Voyager/Linux systems, 
> > which are using _ancient_ 486/P5 era CPUs.
> 
> That's factually incorrect on both counts. [...]

Please correct my numbers and facts then, if you know them.

> [...]  But the real point is that kernel development isn't a 
> popularity contest, it's about the technical merits of the code 
> ... something you've been conspicuously avoiding.

The popularity and relevance (and obscolescence) of a hardware 
platform is certainly a significant factor in architecture 
maintenance decisions (such as whether and when to merge a piece of 
code or not) - are you saying it is not?

This is not just a new, well-isolated driver to put into drivers/* - 
this is about the most used Linux architecture code.

> > Two of these systems are in your house, two are somewhere 
> > unknown: their owners certainly never sent bugreports against 
> > recent mainline kernels (Voyager didnt even _build_ for a couple 
> > of straight kernel releases), and i suspect those boxes are 
> > probably decommissioned already.
> > 
> > A single core on my run-of-the-mill x86 laptop has more 
> > computing power than all Voyager/Linux systems on the planet, 
> > combined. And you now want to add back support to the mainline 
> > arch/x86 code, which we are trying hard to keep running on 
> > millions of x86 Linux systems?
> 
> Well, what can I say, if your laptop is the speed standard for 
> acceptable architectures, then I suppose you'll be removing all of 
> the embedded architectures as well?

I did not say or suggest that, and you clearly misrepresented my 
argument - so it seems to me you are not really interested in having 
an objective argument about this.

My argument was:

  " A single core on my run-of-the-mill x86 laptop has more
    computing power than all Voyager/Linux systems on the planet,
    combined. "

How can you deform this plain-English fact that exposes the shocking 
irrelevance of Voyager/Linux into suggesting that i'd be "removing 
all of the embedded architectures as well" ?

It's an insane suggestion. [ In reality the combined computing power 
of all ARM or MIPS chips on this planet would certainly beat the 
currently fastest supercomputer. (it would be a few orders of 
magnitude faster, most likely) ]

> > You still have not given proper justification for doing that ...
> 
> The justification is that I'm prepared to maintain it.

Sorry, but your willingness to maintain it _now_, means little to 
me. What matters to me is the existing track record of Voyager:

  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.

... it was broken up to the point where we removed it from the x86 
devel tree. It only built in your out-of-tree repository. As far as 
the upstream kernel users are concerned Voyager did not exist since 
v2.6.27.0.

And the further justification (beyond all the things i mentioned in 
this and prior mails) i'm giving you for not pulling it right now is 
that Voyager/Linux is obviously irrelevant: with just about 4 boxes 
on the planet.

If that factor changes materially then the decision could be 
reconsidered.

> > Sorry to be the one to say 'no', but the reasons you gave so far 
> > were not very convincing to me.
> >  
> > Anyway, you seem to be willing to maintain this code it out of tree. 
> > If someone owns such an ancient Voyager box and wants to test a new 
> > kernel then your tree is a good starting point for doing that. 
> > There's really no pressing need to have this in mainline.
> 
> So the message you want to be giving out as a maintainer is that 
> everything should be developed upstream, except when it's x86?

No, the message i'm giving out as a maintainer is that everything 
that did not get merged due to being judged problematic or 
irrelevant (or both) by a maintainer can still be maintained out of 
tree, so that it can _prove_ the maintainer wrong: i.e. that it is 
useful and still relevant.

Get a user base. Find bugs on those boxes. Prove it that it matters 
to Linux. Then we can admit our mistake in a couple of cycles and 
merge it. There's been projects that lived out of tree for a decade, 
literally. There's life outside the upstream kernel too - it's not 
like your code has been destroyed. And you already expressed 
willingness to maintain it - and you are the only developer able to 
boot such a box. So please do it even if this code is not upstream 
for a few kernel cycles, for the sake of Voyager users.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists