WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Xen/ia64 presentation

To: Hollis Blanchard <hollisb@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Xen/ia64 presentation
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 27 Apr 2005 20:31:41 +0100
Cc: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 27 Apr 2005 19:33:34 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <426FE40C.60102@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <516F50407E01324991DD6D07B0531AD535AFC4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <426FE40C.60102@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 27 Apr 2005, at 20:12, Hollis Blanchard wrote:

Maintaining close ties to Linux makes it much easier to "go back to
the well".  I remember that Xen 1.0 removed a lot of the early
"start of day" code for other (e.g. Cyrix) processors; when the
user community grew and some users wanted to run on other processors,
the Xen team went back and grabbed the code from Linux.

I don't necessarily see divergence as good or bad, but I don't rule it
out. The Cyrix thing you described is a fine example of a lazy
algorithm, which I can see you have lots of respect for. :) Remove
dubious code, and if it turns out somebody complains (causing a code
fault ;), it can be re-added. Any code that's kept has to be maintained,
and if no users even excercise it then it's quite likely to bitrot
anyways. For example, Linux supports i386 processors as well, but I
suspect it would be counter-productive to attempt that in Xen.

Exactly: within an architecture I think it makes sense to keep it simple but fault in features. I personally fear premature feature-itis and flexibility: I'd much rather add things in as they become necessary, whatever the project. In the case of Xen, we would otherwise forever be a gross hard-to-maintain patch on the side of Linux.

The other concern that Dan talks about is what the arch-independent interface should look like -- I think that this will look really rather different between an OS and a hypervisor. For example, an arch with a software-managed TLB will not want to cope with generic interfaces supporting 3- or 4-level page tables, although that might well make sense in an OS (where you need some kind of address-space management structure anyway, and might as well look like a pagetable).

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>