Re: [MirageOS-devel] Mirage/ARM plans

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On Mon, May 12, 2014 at 10:28:15AM +0100, Thomas Leonard wrote:
> Here are the things I think need to happen to get Mirage working on ARM:

Great summary!  My comments inline:

> 
> - Update Mini-OS to support both x86 and ARM (done but not yet merged).

This refers to upstream Xen MiniOS, right?  Do you think it's worth
modifying the MiniOS repository to build fully independently of Xen (so
that we can extract the git subtree) and install its header files and
.a/.lds files somewhere that can be picked up by the mirage-platform
build?

This would require some extra ifdefs to disable some of the MiniOS
functionality we dont need (its threads, xenstore, and device drivers),
but I suspect upstream will be sympathetic to such changes to toggle
off functionality.
 
>  -Sort out Mini-OS's recursive symlinks (causes trouble for ocamlbuild
> and opam).
> - Change the build system to use the upstream Makefiles rather than
> - Update "kernel" in mirage-platform to the lastest version of Mini-OS
> (adding ARM support).

If we do the above, then OPAM would never build the C bits (treating
MiniOS as an external library instead).  Would make cross-compilation much
easier in the future too...

> - Update "dietlibc" to the latest version (adding ARM support), or
> switch to a different libc.
> - Create "xencaml" component for the Mini-OS OCaml stubs (keeping them
> separate from Mini-OS).

Yep, that would make supporting multiple compiler versions much easier
too.

> - Sort out the "include" directory. Not clear where these files came from.
>   Might be good to separate out headers from Mini-OS vs headers from libc, 
> etc.

This started off as a well-intentioned thing -- instead of confusingly
overlapping include directories, we moved them into one area to ensure
that they were all in sync.  Worked well early on, but makes maintenance
essentially impossible...

Separating out the internal MiniOS headers from libc could be done in the
same style as kernel headers, with MiniOS headers treated as something not
to expose to 'userspace' without a specific reason.  It's very likely that
we will expose a lot of low-level state to OCaml in the future (after all,
taking advantage of hardware-specific functionality during compilation is
one of the main goals), but we can do so in a more controlled way than is
currently done.

> - Update "include/xen" with the latest Xen headers (adding ARM support).
> ocamlbuild, for ease of merging in future.
> - Get ARM support for "libm".
> - Test the above changes on x86 (is there a test suite?).
> - Test on ARM.

No test suite in MiniOS, but running the Mirage network or block skeletons
with some decent load is a pretty good way to stress a lot of critical
subsystems.

> - Improve stack handling in Mini-OS (at a minimum, start with a bigger
> fixed-size stack).
>   Then enable stack growing, or at least detect stack overflows.

Yep, we can get pretty far with a large fixed-size stack, but detecting
stack overflows and faulting with the right exception would certainly be
safer.

> libc options:
> 
> We need to change to a new libc as dietlibc is GPL.
> 
> I'm not sure how far mirage-platform's dietlibc has diverged from the
> upstream version. If it's only a little, it might be eaiser to update
> to dietlibc 0.33, get everything working with that and then switch to
> a new libc. But if it's heavily patched, it might be better to start
> with a fresh libc right away.

It hasn't been heavily patched, but a lot of functionality was disabled.
I suspect that it would just be easier to begin from scratch with a new
libc infrastructure as some assumptions (particularly around the order
that ctors are run) may not hold in the latest release.  That leads to
fairly hard-to-track issues...
> 
> Options include:
> 
> - FreeBSD's libkern (is there some documentation for this?).
> 
> - Bionic (BSD) - http://en.wikipedia.org/wiki/Bionic_%28software%29
>   Used in Android; so probably good ARM support.
> 
> - newlib (scary mix of licenses) - https://sourceware.org/newlib/
>   Not clear from web-site what advantages it provides or what its goals are.
> 
> - uClibC (LGPL) - http://www.uclibc.org/
>   Designed for very small systems (e.g. without an MMU).
>   Anil mentioned that LGPL may worry the lawyers, though LGPL sounds
> like a good option to me.
> 
> - musl (MIT) - http://www.musl-libc.org/intro.html
>   Seems to have a focus on correctness and robustness.
> 
> - eCos (modified GPL; LGPL-like)
>   Aims to be highly configurable for custom builds.

To clarify my LGPL concerns, it's mainly that having a single license for
the core components of the project is highly desirable.  Since our OCaml
libraries are BSD/ISC licensed where possible, I prefer source code that
matches this for the runtime too.

For the choice of libcs, I think we should avoid the ones designed for
embedded systems, since they often sacrifice performance in favour of
lower resource usage.  Our target for the Xen ports are fairly beefy CPUs
in comparison to the usual places where uclibC runs, for instance.

Despite its relative youth, I do like the look of musl, and it's actively
developed.  It also includes a C99 math library, which would save us
pulling in a *BSD libm.  Someone (independently) submitted an OPAM
compiler switch for musl here, due to its nice static linking support:
https://github.com/ocaml/opam-repository/tree/master/compilers/4.01.0/4.01.0%2Bmusl

> These are GPL, so not useful:
> 
> - dietlibc (GPL) - aims for small code size
> - Linux klibc (mostly BSD, but some GPL) - for Linux initrd
> 
> The musl project has a comparison table for some features of musl,
> uClibc, dietlibc and glibc:
> 
>   http://www.etalabs.net/compare_libcs.html
> 
> Let me know if you have other suggestions or can rule out any of the
> above.

It looks like a shortlist between libkern (which needs to be extracted
from FreeBSD) and libmusl to me...

-anil

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel