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

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

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

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

Is definitely simpler, and easier to prove that you're not going to
piss on anyone else's shoes in the process.

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

I'd think it'd be easy enough to break it down by subsystem? Not that
some bits won't be left over, but should break the back of it. We'd
need a common style/approach first though. Apologies for missing the 
conversation on Wednesday at OLS, they rudely scheduled me to present 
my OLS paper in that timeslot ;-) 

My experience from doing the Summit stuff was that the hard bit is 
refactoring the existing functions to create suitable abstraction points - 
clean breaks for where you want to change the code. That way you don't 
end up copying chunks of code everywhere. We could do that fairly easily
in parallel I think, and it probably wouldn't get scuppered too much by
Xen code changes (the hook points are less likely to change). However,
it'll probably cause horrible churn for anyone trying to keep the Xen
code in sync with mainline ;-)

OK, so I forgot question (3).... or rather I think we covered it before
but I forgot the answer. Are we going to try to do i386 or x86_64 first,
or both at the same time? Personally I'd prefer to do i386 first, as the
subarch stuff is in place there, and it should be easier, but maybe that's
just me.

M.


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