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

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

On 04/12/14 14:40, Andrew Cooper wrote:
There are already-identified issues such as MiniOS leaking things like
ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
to fix.

I think splitting things like the stub libc away from the "MiniOS Xen
Framework" is also a good idea.  Ideally, the result of a "MiniOS Build"
would be a small set of .a's which can then be linked against some
normal C to make a minios guest.  (How feasible this is in reality
remains to be seen.)

I've become increasingly convinced that we (rump kernels) would like to use MiniOS as a small firmware library that just takes care of bootstrap and provides a high-level interface to the Xen hypervisor.

A componentized MiniOS is not critical from our perspective, as long as you can can compile things out. We always want the minimal version, and can use build flags to produce it. Notably, thanks to recent work by Martin, MiniOS is already compiled to a .o in the rumprun-xen repository, and then just linked into the final image.

What is critical for us, however, is reducing the amount of support routines needed by MiniOS. Currently, the software stack in rumprun-xen is confusing because MiniOS partially uses libc which runs on top of the rump kernel which runs on top of MiniOS... This confusion springs from MiniOS providing its own libc, and while it's ok for standalone MiniOS to use its own libc, we do not. To make things as simple as possible, I don't want our [compiled] version of MiniOS to depend on anything from libc.

So, while I agree with everyone that merging is a good idea, the realist in me remains in doubt just like you do; is it feasible to both trim MiniOS to be minimal enough for our needs and keep it maximal enough for yours? Or does that result in too many ifdef noodles?

From a not-public-API point of view, all you have to worry about is that
the existing minios stuff in xen.git, including the stubdom stuff,
continues to work.  We have never made any guarantees to anyone using
minios out-of-tree.

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.

  - antti

Xen-devel mailing list



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