On 05/12/14 18:31, Martin Lucina wrote:
po...@iki.fi said:
I wonder if work is minimized if we attempt to merge before or after
we (I?) take the carving knife for a second round in the rumprun-xen
repo to minimize MiniOS to run only on top of itself.
Before, I think. Minimizing our copy of Mini-OS duplicates what we would
need to do to the upstream copy.
I think the steps are roughly as follows:
a) split the current rumprun-xen build out of the Mini-OS Makefile.
b) replace our fork of Mini-OS with the vanilla upstream Mini-OS.
c) re-apply my work and your work, while checking things keep working
with upstream xen.git, until we get rumprun-xen working again.
c) will leave us with a set of patches to upstream.
Does this make sense? It's a fair amount of work but mostly retracing steps
we've already done.
It'd help if we had a full list of "what exactly needs to keep working
upstream", see my other reply to Andrew. Maybe also osstest building and
running Mini-OS related tests off our branch while we do the work? (Ian:
ping? Doable?)
It'd also help if we had a full list of "what exactly needs to be done
to downstream". That's why I'm not convinced by a list which ignores
"d) perform the unknown steps to reach our goal" (which were painted in
broad strokes in my previous mail).
Actually, it convinced me more of the opposite: wait before attempting
full merge. However, if someone's merge finger is twitching, a
pseudo-merge with changes like the namespace protection and introducing
a clean "libminios" split is nice. But, again, is it more or less work
doing that piecemeal or when all the puzzle pieces are known?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel