All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
	Ian Pratt <Ian.Pratt@cl.cam.ac.uk>,
	Steven.Hand@cl.cam.ac.uk, Christian.Limpach@cl.cam.ac.uk,
	Keir.Fraser@cl.cam.ac.uk
Subject: arch/xen is a bad idea
Date: 14 Dec 2004 19:59:50 +0100	[thread overview]
Message-ID: <p73acsg1za1.fsf@bragg.suse.de> (raw)
In-Reply-To: <41BF1983.mailP9C1B91GB@suse.de.suse.lists.linux.kernel>

"Andi Kleen" <ak@suse.de> writes:

[again this time with subject. sorry for the screwup]
[very late answer]

> Stunned silence I guess - merging an architecture is
> usually much more controversial ;)

In my opinion it's still an extremly bad idea to have arch/xen
an own architecture. It will cause a lot of work long term
to maintain it, especially when it gets x86-64 support too.
It would be much better to just merge it with i386/x86-64.

Currently it's already difficult enough to get people to
add fixes to both i386 and x86-64, adding fixes to three
or rather four (xen32 and xen64) architectures will be quite bad.
In practice we'll likely get much worse code drift and missing
fixes. Also I still suspect Ian is underestimating how much
work it is long term to keep an Linux architecture uptodate.

I cannot imagine the virtualization hooks are intrusive anyways. The
only things it needs to hook idle and the page table updates, right?
Doing that cleanly in the existing architectures shouldn't be that
hard.

I suspect xen64 will be rather different from xen32 anyways
because as far as I can see the tricks Xen32 uses to be
fast (segment limits) just plain don't work on 64bit
because the segments don't extend into 64bit space.
So having both in one architecture may also end up messy.

And i386 and x86-64 are in many pieces very different anyways,
I have my doubts that trying to mesh them together in arch/xen
will be very pretty.

Also the other thing I'm worried about is that there is no clear
specification on how the Xen<->Linux interface works. Assuming
there will be other para Hypervisors in the future too will we
end up with even more virtual architectures? It would be much
better to have at least a somewhat defined "linux virtual interface"
first that is actually understood by multiple people outside
the Xen group.

I think before merging stuff the hypervisor interfaces need to be
discussed on linux-kernel. Splitting the patches and posting them
as individual pieces for i386 with good description will be a good
first step for that.

-Andi

       reply	other threads:[~2004-12-14 18:59 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 ` Andi Kleen [this message]
2004-12-14 19:35   ` arch/xen is a bad idea 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
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=p73acsg1za1.fsf@bragg.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=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.