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

[Rik van Riel <riel@xxxxxxxxxx>]

On Tue, 2 Aug 2005, Martin J. Bligh wrote:

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

> 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 would definitely prefer to start out with (A).  The sooner we
can get xenolinux merged, the less time I need to spend on merging
the same patches into kernel RPMs over and over again, and the
more time I will have to actually work on development of Xen ;)

My main question is, how can we share the work we're doing, and
how can we merge the prepare-for-upstream changes into the
linux-sparse tree ?

-- 
The Theory of Escalating Commitment: "The cost of continuing mistakes is
borne by others, while the cost of admitting mistakes is borne by yourself."
  -- Joseph Stiglitz, Nobel Laureate in Economics

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