From: Thomas Gleixner <tglx@linutronix.de>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: David Miller <davem@davemloft.net>,
"jeremy@goop.org" <jeremy@goop.org>,
"mingo@elte.hu" <mingo@elte.hu>,
Dan Magenheimer <dan.magenheimer@oracle.com>,
"avi@redhat.com" <avi@redhat.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Keir Fraser <Keir.Fraser@eu.citrix.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"gregkh@suse.de" <gregkh@suse.de>,
"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
Ian Pratt <Ian.Pratt@eu.citrix.com>,
"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
ksrinivasan <ksrinivasan@novell.com>,
"EAnderson@novell.com" <EAnderson@novell.com>,
"wimcoekaerts@wimmekes.net" <wimcoekaerts@wimmekes.net>,
Stephen Spector <stephen.spector@citrix.com>,
"jens.axboe@oracle.com" <jens.axboe@oracle.com>,
"npiggin@suse.de" <npiggin@suse.de>
Subject: Re: Xen is a feature
Date: Tue, 2 Jun 2009 17:23:28 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.00.0905311607560.3379@localhost.localdomain> (raw)
In-Reply-To: <4A1FCE8E.2060604@eu.citrix.com>
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
next prev parent reply other threads:[~2009-06-02 15:30 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 23:25 [GIT PULL] Xen APIC hooks (with io_apic_ops) Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 01/17] xen/dom0: handle acpi lapic parsing in Xen dom0 Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 02/17] x86: add io_apic_ops to allow interception Jeremy Fitzhardinge
2009-05-25 3:54 ` Ingo Molnar
2009-05-27 7:17 ` Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 03/17] xen: implement io_apic_ops Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 04/17] xen: create dummy ioapic mapping Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 05/17] xen: implement pirq type event channels Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 06/17] x86/io_apic: add get_nr_irqs_gsi() Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 07/17] xen/apic: identity map gsi->irqs Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 08/17] xen: direct irq registration to pirq event channels Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 09/17] xen: bind pirq to vector and event channel Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 10/17] xen: pre-initialize legacy irqs early Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 11/17] xen: don't setup acpi interrupt unless there is one Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 12/17] xen: use acpi_get_override_irq() to get triggering for legacy irqs Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 13/17] xen: initialize irq 0 too Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 14/17] xen: dynamically allocate irq & event structures Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 15/17] xen: set pirq name to something useful Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 16/17] xen: fix legacy irq setup, make ioapic-less machines work Jeremy Fitzhardinge
2009-05-12 23:25 ` [PATCH 17/17] xen: disable MSI Jeremy Fitzhardinge
2009-05-19 12:35 ` [GIT PULL] Xen APIC hooks (with io_apic_ops) Ingo Molnar
2009-05-20 17:57 ` Jeremy Fitzhardinge
2009-05-25 4:10 ` Ingo Molnar
2009-05-26 12:46 ` [Xen-devel] " George Dunlap
2009-05-26 18:26 ` Avi Kivity
2009-05-26 19:18 ` Dan Magenheimer
2009-05-26 19:41 ` Avi Kivity
2009-05-28 0:13 ` Ingo Molnar
2009-05-28 0:49 ` Jeremy Fitzhardinge
2009-05-28 3:47 ` Dan Magenheimer
2009-05-28 14:26 ` George Dunlap
2009-05-29 0:45 ` Xen is a feature Jeremy Fitzhardinge
2009-05-29 1:27 ` Greg KH
2009-05-29 4:05 ` David Miller
2009-05-29 6:37 ` Jaswinder Singh Rajput
2009-05-29 6:51 ` David Miller
2009-05-29 12:01 ` George Dunlap
2009-05-29 14:14 ` Pasi Kärkkäinen
2009-05-29 21:29 ` David Miller
[not found] ` <87tz33ep1b.fsf@basil.nowhere.org>
2009-05-29 21:31 ` [Xen-devel] " Jeremy Fitzhardinge
2009-05-29 23:09 ` Nakajima, Jun
2009-05-29 23:26 ` Jeremy Fitzhardinge
2009-06-02 15:23 ` Thomas Gleixner [this message]
2009-06-02 16:41 ` George Dunlap
2009-06-02 17:28 ` Chris Friesen
2009-06-02 17:46 ` Linus Torvalds
2009-06-02 18:02 ` Linus Torvalds
2009-06-02 18:59 ` Avi Kivity
2009-06-07 9:13 ` Ingo Molnar
2009-06-07 10:01 ` Avi Kivity
2009-06-07 10:35 ` Ingo Molnar
2009-06-07 12:46 ` Avi Kivity
2009-06-07 13:02 ` Jaswinder Singh Rajput
2009-06-04 14:02 ` [Xen-users] " Thomas Goirand
2009-06-02 18:59 ` Thomas Gleixner
2009-06-03 19:49 ` Bill Davidsen
2009-06-03 20:20 ` Thomas Gleixner
2009-06-03 22:37 ` Bill Davidsen
2009-06-03 23:29 ` Frans Pop
2009-06-04 13:21 ` George Dunlap
2009-06-04 15:10 ` Theodore Tso
2009-06-04 15:31 ` Chris Friesen
2009-06-05 4:14 ` Bill Davidsen
2009-06-05 4:55 ` Chris Friesen
2009-06-02 22:40 ` Steven Rostedt
2009-06-02 23:28 ` Merge Xen (the hypervisor) into Linux Ingo Molnar
2009-06-03 0:00 ` Dan Magenheimer
2009-06-03 0:32 ` Thomas Gleixner
2009-06-03 2:43 ` Theodore Tso
2009-06-03 3:42 ` Steven Rostedt
2009-06-03 4:49 ` Dan Magenheimer
2009-06-03 4:58 ` David Miller
2009-06-03 5:07 ` Steven Rostedt
2009-06-03 5:22 ` Steven Rostedt
2009-06-03 12:03 ` George Dunlap
2009-06-03 19:05 ` Theodore Tso
[not found] ` <4A27CF94.1050903@gmx.de>
2009-06-04 14:03 ` [Xen-users] " Steven Rostedt
2009-06-03 7:28 ` Gerd Hoffmann
2009-06-03 8:47 ` Alan Cox
2009-06-03 9:09 ` Gerd Hoffmann
2009-06-03 9:20 ` Keir Fraser
2009-06-03 11:15 ` Theodore Tso
2009-06-03 11:39 ` Keir Fraser
2009-06-03 11:41 ` Gerd Hoffmann
2009-06-03 1:00 ` Joel Becker
2009-06-03 2:00 ` david
2009-06-03 7:59 ` Alan Cox
2009-06-03 8:07 ` Christian Tramnitz
2009-06-04 18:53 ` Linus Torvalds
2009-06-05 0:09 ` Samuel Thibault
2009-06-05 0:18 ` David Miller
2009-06-05 0:54 ` Linus Torvalds
2009-06-03 17:31 ` Chris Friesen
2009-06-03 17:36 ` Alan Cox
2009-06-02 23:41 ` Xen is a feature Thomas Gleixner
2009-05-30 2:19 ` [Xen-devel] " Andy Burns
2009-05-26 21:19 ` [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops) Gerd Hoffmann
2009-05-27 10:14 ` George Dunlap
2009-05-24 20:10 ` Avi Kivity
2009-05-25 3:51 ` Ingo Molnar
2009-05-25 4:55 ` Avi Kivity
2009-05-25 5:06 ` Ingo Molnar
2009-05-25 5:12 ` Avi Kivity
2009-05-25 5:19 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2009-05-29 11:48 Xen is a feature Tomasz Chmielewski
2009-05-29 13:08 Sander Eikelenboom
2009-05-31 21:11 devzero
2009-06-02 22:44 Sander Eikelenboom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0905311607560.3379@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=EAnderson@novell.com \
--cc=Ian.Pratt@eu.citrix.com \
--cc=Keir.Fraser@eu.citrix.com \
--cc=avi@redhat.com \
--cc=dan.magenheimer@oracle.com \
--cc=davem@davemloft.net \
--cc=george.dunlap@eu.citrix.com \
--cc=gregkh@suse.de \
--cc=jens.axboe@oracle.com \
--cc=jeremy@goop.org \
--cc=ksrinivasan@novell.com \
--cc=kurt.hackel@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=stephen.spector@citrix.com \
--cc=torvalds@linux-foundation.org \
--cc=wimcoekaerts@wimmekes.net \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
--cc=xen-users@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox