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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

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