[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.