Re: [MirageOS-devel] Including a C Library in a Mirage Xen Kernel

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 16 Dec 2013, at 19:10, James Bielman <jamesjb@xxxxxxxxxxx> wrote:

> Hi all,
> 
> I'm using Mirage to build a Xen kernel, and would like to include a C
> library compiled against the Mirage runtime (along with OCaml stubs for it).
> 
> My question is about the build process, especially when installing via
> OPAM.  mirage-platform doesn't seem to install the headers for its
> dietlibc anywhere that a dependent project can find them.
> 
> I could require a user to have a checkout of mirage-platform at hand to
> build, but that feels awkward when previously everything could be
> installed via OPAM except for the kernel itself (which builds with mirari).
> 
> Does anyone have any recommendations about how to export build
> dependencies like header files (and also matching the CFLAGS/LDFLAGS
> used for the Mirage runtime would be nice to have as well).

Hi James,

Good timing; you've hit on something I have active diffs for in my
trees.  The dietlibc headers aren't installed deliberately since the plan
was always to use it for bootstrapping and not require the whole thing
to be in the tree (hard to maintain).

The only bits we really use now are the malloc memory management functions,
and the printf calls.  As part of Gabor Pali's work to port Mirage to a
FreeBSD kernel module, he showed that the libkern present in FreeBSD gives
us a pretty good printf implementation (caveat: no floating point printing).

However, we do need a libc environment for SSL in the short term too, so
we can't escape some build system refactoring.  Does your C library have
any special requirements beyond the functionality currently provides by
dietlibc?

Current solution: fork mirage-platform and add your library directly into
the repository (there are several other stubs in kernel/ that use the OCaml
headers, such as checksum_stubs.c).  You can still distribute your fork via
a custom OPAM remote that overrides mirage-platform-xen.

Medium term solution: I'm splitting out the dietlibc dependency from the
MiniOS kernel, and merging us back to the MiniOS version found in Xen
upstream.  I'd like to bolt on a libm and libc on top of this, but I need
to investigate the latest in embedded cross-compilation, since this also
needs to support ARM (and more experimentally, MIPS64) as well as x86.
Anyone have any recommendations in this space?

I'm CCing Adam Wick on this too, since he also has a libm extracted from
OpenBSD.  Sharing this sort of code between HalVM/Mirage will make longer
term maintenance a lot easier, so I'm happy to adopt something if it can
be easily split out of the HalVM tree.

Alternative medium term solution: the ocamllabs/ocaml-ctypes library will
get stub generation support shortly, which may make it easier to interface
with the OCaml runtime.  It can also talk over a shared memory channel, so
C libraries could be treated as RPC servers.

Luckily, most of this work can happen behind the scenes, as the OPAM package
for mirage-xen can pull in the new dependencies without affecting existing
code.

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