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

[Antti Kantee <pooka@xxxxxx>]

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