Re: [Xen-devel] RFC: Cleaning up the Mini-OS namespace

[Antti Kantee <pooka@xxxxxx>]

On 05/12/14 18:31, Martin Lucina wrote:
> pooka@xxxxxx 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel