From: Andi Kleen <ak@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andi Kleen <ak@suse.de>, Ian Pratt <Ian.Pratt@cl.cam.ac.uk>,
Rik van Riel <riel@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
akpm@osdl.org, Steven.Hand@cl.cam.ac.uk,
Christian.Limpach@cl.cam.ac.uk, Keir.Fraser@cl.cam.ac.uk
Subject: Re: arch/xen is a bad idea
Date: Thu, 16 Dec 2004 15:09:54 +0100 [thread overview]
Message-ID: <20041216140954.GA29761@wotan.suse.de> (raw)
In-Reply-To: <1103201656.3804.7.camel@localhost.localdomain>
On Thu, Dec 16, 2004 at 12:54:17PM +0000, Alan Cox wrote:
> On Iau, 2004-12-16 at 04:01, Andi Kleen wrote:
> > That is exactly the part that is wrong currently imho. The arch/xen
> > interface is a mess and in its current form unlikely to be maintainable.
>
> It seems maintainable and well documented to me. I just don't see where
> your problem is with this. The kernel/hypervisor interface is clear, and
> the arch/xen code seems quite sane.
The main problem I see is that it is source code copy, and especially
when they both support i386 and x86-64 there will be no sane
way to keep it all synchronized with the i386 and x86-64
code bases. It's already hard from a single source like I can
attest from x86-64, with two sources it will be likely much more
difficult longer term. I just can't see it working well in
practice. It will be also nasty for people doing changes
because they will need to duplicate i386+x86_64 changes four
times in the worst case (i386,x86_64,xen32,xen64)
I guess it may be acceptable if we were maintaining obscure Lance
drivers this way ;_), but for a important architecture it just doesn't seem
like the right approach to me.
Also e.g. for non performance critical
things like changing MTRRs or debug registers it would be IMHO much
cleaner to just emulate the instructions (the ISA is very well
defined) and not change the kernel here. From a look at Ian's list
the majority of the changes needed for Xen actually fall into
this category.
I suspect when the kernel is only changed for the truly performance
critical interfaces that cannot be efficiently emulated (like idle/timers/page
table updates) the required changes for the para virtualization will become
much more manageable and can be cleanly integrated into the respective ports.
And as Pavel points out first merging arch/xen and then migrating
into i386 and x86_64 like it was proposed sounds extremly hard and is
probably not really practical.
-Andi
next prev parent reply other threads:[~2004-12-16 14:09 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <41BF1983.mailP9C1B91GB@suse.de.suse.lists.linux.kernel>
2004-12-14 18:59 ` arch/xen is a bad idea Andi Kleen
2004-12-14 19:35 ` Antonio Vargas
2004-12-14 22:40 ` Ian Pratt
2004-12-15 4:49 ` Andi Kleen
2004-12-16 0:09 ` Alan Cox
2004-12-16 4:01 ` Andi Kleen
2004-12-16 12:54 ` Alan Cox
2004-12-16 14:09 ` Andi Kleen [this message]
2004-12-16 13:19 ` Alan Cox
2004-12-16 14:28 ` Andi Kleen
2004-12-16 20:37 ` Ian Pratt
2004-12-16 18:26 ` Andrew Morton
2004-12-16 18:57 ` Alan Cox
2004-12-16 21:00 ` Ian Pratt
2004-12-16 21:03 ` Andrew Morton
2004-12-16 21:36 ` Ian Pratt
2004-12-16 21:39 ` Rik van Riel
2004-12-17 6:04 ` Andi Kleen
2004-12-17 8:26 ` Ian Pratt
2004-12-16 22:04 ` Philip R Auld
2004-12-16 23:08 ` Rik van Riel
2004-12-17 2:07 ` Philip R Auld
2004-12-17 6:03 ` Andi Kleen
2004-12-15 11:49 ` Pavel Machek
2004-12-16 1:14 ` Ian Pratt
2004-12-16 1:26 ` Pavel Machek
2004-12-16 14:21 ` Andi Kleen
2004-12-16 22:45 ` Bill Davidsen
2004-12-16 23:09 ` Rik van Riel
2004-12-20 15:08 ` arch/xen clue? Dorn Hetzel
2004-12-20 15:15 ` Ian Pratt
2004-12-20 15:23 ` Anton Altaparmakov
2004-12-20 15:34 ` Måns Rullgård
2004-12-15 11:51 ` arch/xen is a bad idea Pavel Machek
2004-12-17 16:05 ` William Lee Irwin III
2004-12-18 17:57 ` Ian Pratt
2005-02-25 11:43 ` Andrew Morton
2005-02-25 11:55 ` kernel 2.6.8-24.11-smp errors Marcel Smeets
2005-02-25 12:07 arch/xen is a bad idea Ian Pratt
2005-02-25 15:01 ` Andi Kleen
2005-02-25 22:37 ` Andrew Morton
2005-02-26 20:41 Ian Pratt
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=20041216140954.GA29761@wotan.suse.de \
--to=ak@suse.de \
--cc=Christian.Limpach@cl.cam.ac.uk \
--cc=Ian.Pratt@cl.cam.ac.uk \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=Steven.Hand@cl.cam.ac.uk \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.