Message-ID: <alpine.LFD.2.00.0905311607560.3379@localhost.localdomain>
Date:	Tue, 2 Jun 2009 17:23:28 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	George Dunlap <george.dunlap@...citrix.com>
cc:	David Miller <davem@...emloft.net>,
	"jeremy@...p.org" <jeremy@...p.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	"avi@...hat.com" <avi@...hat.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Keir Fraser <Keir.Fraser@...citrix.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"kurt.hackel@...cle.com" <kurt.hackel@...cle.com>,
	Ian Pratt <Ian.Pratt@...citrix.com>,
	"xen-users@...ts.xensource.com" <xen-users@...ts.xensource.com>,
	ksrinivasan <ksrinivasan@...ell.com>,
	"EAnderson@...ell.com" <EAnderson@...ell.com>,
	"wimcoekaerts@...mekes.net" <wimcoekaerts@...mekes.net>,
	Stephen Spector <stephen.spector@...rix.com>,
	"jens.axboe@...cle.com" <jens.axboe@...cle.com>,
	"npiggin@...e.de" <npiggin@...e.de>
Subject: Re: Xen is a feature

On Fri, 29 May 2009, George Dunlap wrote:
> David Miller wrote:
> > I don't see Ingo's comments, whether I agree with them or not, as
> > an implication of Xen being niche.  Rather I see his comments as
> > an opposition to how Xen is implemented.
> >   
> It's in his definition of "improving Linux".  Jeremy is saying that allowing
> Linux to run as dom0 *is* improving Linux.  The lack of dom0 support is at
> this moment making life more difficult for a huge number of Linux users who

Exactly that's the point. Adding dom0 makes life easier for a group of
users who decided to use Xen some time ago, but what Ingo wants is
technical improvement of the kernel.

There are many features which have been wildly used in the distro
world where developers tried to push support into the kernel with the
same line of arguments.

The kernel policy always was and still is to accept only those
features which have a technical benefit to the code base.

I'm just picking a few examples:

Aside of the paravirt, which seems to expand through arch/x86 like a
hydra, the new patches sprinkle "if (xen_...)" all over the
place. These extra xen dependencies are no improvement, they are a
royal pain in the ... They are sticky once they got merged simply
because the hypervisor relies on them and we need to provide
compatibility for a long time.

Aside of that it grows interfaces like pat_disable() just because the
CPU model of Xen is obviously not able to kill the PAT flags in the
CPUid emulation. Why for heavens sake do we have a cpuid paravirt op
when we need to disable stuff seperately which can be disabled by
paravirt functionality already? I don't see this as an improvement
either, it's simple sloppy hackery.

The changelogs of the patches are partially confusing as hell:

commit 7d2b03ff4ae27b7c9e99a421a5b965f20e4bfaab

    x86: fix up flush_tlb_all
    
    - initialize the locks before the first use
    - make sure preemption is disabled
    
    [ Impact: Bug fixes: boot time warning, and crash ]

This patch is in the Xen queue and I assume it's XEN related as we
have not seen anywhere a boot time warning and crash with the current
code AFAICT, but the changelog reads like this is some generic BUG in
the SMP boot code. There is neither a hint to Xen nor to another patch
which caused that problem. While the patch itself is harmless I do not
see what is improved and why the change was necessary in the first
place.

That's what maintainers have to look at and not who is using the code
already and wants to see it merged.

> use Xen, including Mozilla, Debian, and Amazon. Adding dom0 support would
> make Linux even more useful to a wide variety of people not using Xen at the
> moment. 

I really have a hard time to see why dom0 support makes Linux more
useful to people who do not use it. It does not improve the Linux
experience of Joe User at all.

In fact it could be harmful to the average user, if it's merged in a
crappy way that increases overhead, has a performance cost and draws
away development and maintenance resources from other areas of the
kernel.

Aside of that it can also hinder the development of a properly
designed hypervisor in Linux: 'why bother with that new stuff, it
might be cleaner and nicer, but we have this Xen dom0 stuff
already?'.

Thanks,

	tglx
--
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