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

RE: [Xen-merge] xen-merge mailing list

To: "Martin J. Bligh" <mbligh@xxxxxxxxxx>, "Rik van Riel" <riel@xxxxxxxxxx>, <xen-merge@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-merge] xen-merge mailing list
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 2 Aug 2005 18:11:41 +0100
Delivery-date: Tue, 02 Aug 2005 17:09:57 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-merge-request@lists.xensource.com?subject=help>
List-id: xen-merge <xen-merge.lists.xensource.com>
List-post: <mailto:xen-merge@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-merge>, <mailto:xen-merge-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-merge>, <mailto:xen-merge-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-merge-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWXcrBHUUxjOGKQRomI4nEpTf/kPwACcrpg
Thread-topic: [Xen-merge] xen-merge mailing list
> >> 1) What version of Xen code are we going to try to merge? 
> People tell 
> >> me the development stuff here is in quite a bit of flux 
> right now ...
> > 
> > It's in flux, but this is the code base that most people 
> will want by 
> > the time a merge can be completed, so ...

It's not in quite as much flux as it looks :-)

The ongoing changes are all in the xen-specific drivers, changing them
over to use XenBus rather than the nasty control message API. These are
all fully self contained, so should be no problem. 

The new hypervisor time API meant that there have been recent changes to
arch/xen code, but we're not expecting any more, modulo bug fixes.

We just need to pick a Linux version, pick a Xen repo version, do the
merge, and then go through picking up any relevent patches that have
occurred in Linux and Xen arch/xen in the meantime.

> OK, so maybe we should just try to be brave then ;-) I get 
> the feeling we don't *actually* want to be doing this right 
> now, in a couple of months would be better ... but still.

I don't think it'll be that bad to track changes to arch-xen made in the
Xen repo.
  
> >> 2) Do you want to end up with something that switches 
> statically at 
> >> compile time, or dynamically for all standard x86 kernels? Ways to 
> >> cope look to me like:
> >>    A) CONFIG option switch
> >>    B) Function pointers (like ia32 generic subarch stuff)
> >>    C) Dynamic rewriting (like CPU optimization stuff).

I'd vote for A in the first instance, but perhaps bareing B and C in
mind.

Ian


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

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