Re: [MirageOS-devel] Mirage/ARM plans

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 14 May 2014, at 09:31, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> That would certainly be cleaner (and possibly easier too). And it fits
> with Mirage's goal of removing legacy layers from the stack.
> 
> I guess it depends who needs the libc. If it's just for ocaml, it
> would indeed be simpler to patch ocaml. If we want to use other C
> libraries, it might be a problem.
> 
> Personally, I'd be happy to remove functions like Pervasives.open_in
> (which would probably make the capabilities people happy too). But I
> can imagine it might mean some OCaml libraries wouldn't compile
> without modifications, even if that part of them wasn't needed (e.g.
> an XML library that offers the option of loading from a file).
> 
> If compiled with HAVE_LIBC, Mini-OS currently provides a minimal
> filesystem API that lets you open anything under /var/log (writes then
> go to the console), /dev/mem, /dev/ptmx and some things under
> /var/lib/xen.

Supporting a minimal libc was much more important in the earlier
days of Mirage, since we bootstrapped our way up by using existing
C libraries. Nowadays, we don't use the Unix module at all, and so
it's just the Sys module (which is designed to be platform portable)
that needs to be taken into account.

It's useful having the Pervasives channels just for quick debugging,
so redirecting all opens to the standard console output is reasonable.
Similarly, mapping environment variable lookups to a Xenstore subtree
is a pretty good way of representing external parameters that need
to be read at runtime (and make testing in the Unix mode easier).

Actually modifying the OCaml standard library isn't a direction we
should go in, I think, since it removes ABI compatibility with other
OCaml libraries.  I don't believe we need to do much beyond fake out
channels at the moment though.

Note that when I refer to 'libc', I'm really talking about libm (which
is essential), a printf implementation, and malloc/calloc.  There's
very little else we need these days, but it would nice to have some
headers around for other C libraries.  The nocrypto ones have been
specifically designed to not impose a big libc burden though, so we
could skip the headers entirely perhaps.

-anil

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