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
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel