| |
|
 |
|
 |
|
|
|
| |
|
|
xen-merge
Re: [Xen-merge] xen-merge mailing list
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
|
|
|
| |
|
Home