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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/12/14 14:27, Martin Lucina wrote:
> Hi,
>
> In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
> Currently we are using a slightly bastardized fork of the xen.git Mini-OS.
>
> We would like to avoid this turning into a permanent fork. Following
> previous discussion [2] on and openmirage-devel I would like to coordinate
> upstreaming our changes if possible.
>
> The biggest change which needs to be done is cleaning up the Mini-OS
> namespace. This is necessary as we link Mini-OS with the application, rump
> kernel and NetBSD libc to get a full application stack.
>
> The changes as implemented in a semi-automated fashion for the Mini-OS used
> by rumprun-xen can be viewed in the (since merged) pull request at [3]:
>
> - All Mini-OS functions called by rumprun-xen are renamed to minios_* or
>   _minios_* for strictly internal functions, except those in the
>   blkfront_*, netfront_*, pcifront_* and xenbus_* driver namespaces.
> - In the case of drivers, eg. init|shutdown_blkfront are renamed to
>   blkfront_*.
> - All global variables are either manually made local, or placed under
>   the _minios_* namespace, with the exception of HYPERVISOR_shared_info,
>   and those variables under driver namespaces kept above.
> - All callers are updated to use the new names. Where it makes sense,
>   macros such as alloc_page are also renamed into the minios_ namespace.
>
> Questions:
>
> - Is there a general interest in upstreaming this work?
> - Upstream Mini-OS provides things we (rumpkernel.org) don't need (stub
>   "libc", ...). If we are to move to upstream then we will need to do a
>   more general cleanup of Mini-OS to make these pluggable. Again, is there
>   upstream interest in this work?
> - As there is no formal API for Mini-OS. My changes only address the
>   "public" functionality used by rumprun-xen. Other users mileage will
>   vary; who else should I coordinate with?
> - I have not namespaced macros such as local_irq_save(). Should this be
>   done? 
>   
>   Also, the driver namespaces have been preserved (since I was lazy), these
>   should probably be renamed under the minios namespace; it's plausible
>   some day someone will try to link an application with a function called
>   blkfront_init().
>
> All comments and review welcome.
>
> Martin

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

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.

~Andrew


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