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

["Martin J. Bligh" <mbligh@xxxxxxxxxx>]

> Please excuse me from auto-subscribing you to this list, but I figured
> it would be useful to have a list dedicated for discussion about getting
> arch-xen prepared for sending upstream.
> 
> It's pretty clear that we need to move fast on this, lest we get stuck
> with the VMware VMI proposal that just doesn't do what we need to get
> good performance.  I'd much rather get our patch in first and add their
> hooks to our stuff, rather than being forced to work within the
> framework of their very low-level approach. 
> 
> So, how best to go about this? Can we parallelize the work? Where to
> start?

A couple of basic questions:

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

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

Not sure these are actually exclusive ... might be easiest to start with
(A), and evolve it into (C) over time? Certainly (A) will be simpler and
easier to get merged, and if we create the abstraction points right, it
shouldn't be too hard to change over later.

I wouldn't panic too much about the vmware thing, we can stall merging
easily enough, I suspect, as long as it doesn't drag out for months.

M.


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