From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Xen is a feature
Date: Tue, 02 Jun 2009 17:54:44 UTC
Message-ID: <fa.kEuRTks19HE9vDKFA0euYeBn6Qc@ifi.uio.no>

On Tue, 2 Jun 2009, George Dunlap wrote:
>
> idea that changes shouldn't introduce performance regressions.  But there are
> patchqueues that are ready, signed-off by other maintainers, and which Ingo
> admits that he has no technical objections to, but refuses to merge.

I've seen technical objects in this thread. The whole thing _started_ with
one, and Thomas brought up others.

As a top-level maintainer, I can also very much sympathise with the "don't
merge new stuff if there are known problems and no known solutions to
those issues". Is Ingo supposed to just continue to merge crap, when it's
admitted that it has problems and pollutes code that he has to maintain?

The fact is (and this is a _fact_): Xen is a total mess from a development
standpoint. I talked about this in private with Jeremy. Xen pollutes the
architecture code in ways that NO OTHER subsystem does. And I have never
EVER seen the Xen developers really acknowledge that and try to fix it.

Thomas pointed to patches that add _explicitly_ Xen-related special cases
that aren't even trying to make sense. See the local apic thing.

So quite frankly, I wish some of the Xen people looked themselves in the
mirror, and then asked themselves "would _I_ merge something ugly like
that, if it was filling my subsystem with totally unrelated hacks for some
other crap"?

Seriously.

If it was just the local APIC, fine. But it may be just the local APIC
code this time around, next time it will be something else. It's been TLB,
it's been entry_*.S, it's been all over. Some of them are performance
issues.

I dunno. I just do know that I pointed out the statistics for how
mindlessly incestuous the Xen patches have historically been to Jeremy. He
admitted it. I've not seen _anybody_ say that things will improve.

Xen has been painful. If you give maintainers pain, don't expect them to
love you or respect you.

So I would really suggest that Xen people should look at _why_ they are
giving maintainers so much pain.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: Xen is a feature
Date: Tue, 02 Jun 2009 18:09:29 UTC
Message-ID: <fa.vcwWv2IVxrqemdFi8MERtr7u2dw@ifi.uio.no>

On Tue, 2 Jun 2009, Linus Torvalds wrote:
>
> I dunno. I just do know that I pointed out the statistics for how
> mindlessly incestuous the Xen patches have historically been to Jeremy. He
> admitted it. I've not seen _anybody_ say that things will improve.

In case people want to look at this on their own, get a git tree, and run
the examples I asked Jeremy to run:

        git log --pretty=oneline --full-diff --stat arch/x86/kvm/ |
                grep -v '/kvm' |
                less -S

and then go ahead and do the same except with "xen" instead of "kvm".

Now, once you've done that, ask yourself which one is going to be merged
easily and without any pushback.

Btw, this is NOT meant to be a "xen vs kvm" thing. Before you react to the
"kvm" part, replace "arch/x86/kvm" above with "drivers/scsi" or something.

The point? Xen really is horribly badly separated out. It gets way more
incestuous with other systems than it should. It's entirely possible that
this is very fundamental to both paravirtualization and to hypervisor
behavior, but it doesn't matter - it just means that I can well see that
Xen is a f*cking pain to merge.

So please, Xen people, look at your track record, and look at the issues
from the standpoint of somebody merging your code, rather than just from
the standpoint of somebody who whines "I want my code to be merged".

IOW, if you have trouble getting your code merged, ask yourself what _you_
are doing wrong.

			Linus