Re: [MirageOS-devel] Mirage/ARM plans

[Thomas Leonard <talex5@xxxxxxxxx>]

On 12 May 2014 16:10, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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?

Could do. The changes needed to Mini-OS for that are here:

https://github.com/talex5/mirage-platform/commit/53e2675e05df29bae96298844687c14020986e7c

Another option would be to add a "make install-ocamlfind" target to
the upstream Xen copy.

That might mean a bit more downloading for opam to build it, but it
would avoid having a separate repository.

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

That would make it harder for people to install Mirage, though.

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

Currently, Mini-OS's "include" directory contains a symlink "mini-os"
-> ".", so you can refer to a header as e.g. <wait.h>,
<mini-os/wait.h>, <mini-os/mini-os/wait.h>, etc.

I'm trying to clean this up, so every header has a single location,
although it's not clear to me where each file belongs.

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

OK, makes sense.

> 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

I'll try musl first then.

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



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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