[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Current state of the UNIX backend



On 24 May 2013, at 19:23, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote:

> Hi all,
> 
> Apparently, the current state of mirage for UNIX-direct is broken for me.
> 
> Could you test it for me, Mac users:
> 
> cd mirage-skeleton/basic
> mirari configure --unix
> mirari build --unix
> sudo ./mir-hello
> 

One very quick thing I noticed is that the 4.01.0dev+mirage-unix compiler is a 
bit out of date, as it used the old ocplib-endian branch back when the function 
inlining was added by Pierre.

I've modified the compiler descriptions to use ocaml-4.01.0-trunk now, which 
has those changes and a lot more.

However, it does point to the fact that we can separate the compiler dependency 
from the package dependencies much more easily now, thanks to OPAM. 

We have these compilers:
- 4.00.1 : stable release.
- 4.01.0dev+trunk : latest trunk, currently being released.
- pierre's new inline branch [1]

OPAM can build custom package sets against a compiler without reinstalling it, 
by doing "opam switch 4.00.1+custom --alias-of=4.00.1".  This is a fast clone, 
and then a package set can be installed in there just like a normal compiler 
switch.

So, we don't actually need 4.00.1+mirage-unix/xen as a compiler switch any 
more.  I propose simply adding these packages to mainline OPAM:

- mirage-platform-unix (conficts: mirage-platform-xen)
- mirage-platform-xen (conflicts: mirage-platform-unix)
- mirage-net-socket (conflicts: mirage-net-direct)
- mirage-net-direct (conflicts: mirage-net-socket)

The mirage-platform-* packages can provide a mirage ocamlfind package as 
normal.  The only thing I think we need that is missing is a virtual OPAM 
package that depends on either variant, so that upstream packages like 
mirage-www can just depend on "mirage-platform" instead of a specific variant.

Thomas, I need your opinion on if this is sensible or not.  It would eliminate 
the need for the MIRAGE_NET/OS environment variables, and push the remaining 
platform selection logic into OPAM, so that Mirari can just install the right 
set of packages depending on what users want.

[1] described in 
http://www.ocamlpro.com/blog/2013/05/24/optimisations-you-shouldn-t-do.html


> On my test machine it fails with:
> 
> Fatal error: exception Unix.Unix_error(3, "set_nonblock", "")

I'm recompiling now to try this out!

-anil


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.