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 ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
