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

[Martin Lucina <martin@xxxxxxxxxx>]

andrew.cooper3@xxxxxxxxxx said:
> I think this is a very good idea, and I am completely in favour of it.
> 
> 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.)

The approach I used for rumprun-xen is to link all of MiniOS' object files
except the startfile into a final .o with "ld -r". This then allows me to
use "objcopy -w -GPREFIX..." to make all symbols in minios.o *except* those
starting with PREFIX local.

This has the advantage that I only had to rename symbols I really wanted to
keep global rather than going through all the MiniOS code adding "static"
in places where it was missing and sorting out the resulting
inter-dependencies.

> 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.

"Existing minios stuff" meaning the default build of extras/mini-os?

What's up with the -DHAVE_LIBC codepaths in mini-os? Who or what uses
these? Grepping around in stubdom/ doesn't come up with anything...

"Stubdom stuff" meaning the default build of stubdom/, plus the "make
c-stubdom" and "make caml-stubdom" examples documented in README?

Anything else? Sorry if this is obvious but I'm not that familiar with all
of xen.git.

Thanks,

Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel