Re: [MirageOS-devel] Mirage on Xen/ARM status

[Thomas Leonard <talex5@xxxxxxxxx>]

On 14 June 2014 06:55, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 13 Jun 2014, at 17:53, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>
>> I've been going through mirage-skeleton trying all the examples on ARM
>> (Cubietruck running Xen). Here are the results:
>>
>> console: works (I also patched it to try reading from the console, and
>> that works too, after a minor patch to mirage-console; now merged)
>>
>> network: works
>> block: works
>>
>> dns: fails to build
>> Error: No implementations provided for the following modules:
>>         Lwt_unix referenced from
>> /root/.opam/4.01.0/lib/dns/lwt-core.cmxa(Dns_resolver)
>
> This look the euphemistic "architecture independent issue". Need to see how 
> Unix snuck into the ocaml-dns core and add a test for that. Could you create 
> an issue on ocaml-dns for this?

https://github.com/mirage/ocaml-dns/issues/13

Looks like it's just some test code that needs it anyway ("resolving
recoil.org"). If I remove that bit, it answers DNS queries
successfully.

>> ethifv4: seems to work (except for TCP: it shows "TCP retransmission
>> on timer seq = 452901213" instead of connecting)
>
> Can't verify from where I am, but it may just be the stack isn't configured.

Ah, I was just confused about what this does. I thought the IP address
in the code was the one it would listen on, but it looks like it only
uses it until it gets the real address by DHCP. Connecting using the
DHCP-assigned address, it works.

UDP seemed to be working because it logs all packets, regardless of
destination address.

>> io_page: works
>> kv_ro: works (prints YES! a lot, anyway)
>> kv_ro_crunch: works (as kv_ro)
>> ping: works (note: reports UDP traffic as "TCP" due to a bug)
>> stackv4: works (HTTP on 80, TCP on 8080 and UDP on 53)
>>
>> static_website: works, after adding re.str. Otherwise you get:
>> Error: No implementations provided for the following modules:
>>         Re_str referenced from dispatch.cmx
>
> Odd, this was fixed a few weeks ago. Need to look through the pull reqs in 
> case I forgot to merge it.

Ah, you're right. I hadn't updated.

>> So, it's looking pretty good :-)
>
> Yes! The lack of ARM specific issues in the OCaml native code backend isn't a 
> surprise, but still a relief.
>
>> A few random notes:
>>
>> - Lack of progress reports from mirage is a problem on x86, but it's
>> worse on ARM because it's so much slower.
>
> Yes, this one has a bug open on mirage/mirage. We need to tee the output from 
> the tool really.

[ https://github.com/mirage/mirage/issues/205 ]

>> - opam got very confused at one point, somehow uninstalled mirage and
>> then wouldn't bring it back (no error shown). Here's a sample:
>>
>> root@softbuild:~# mirage
>> -bash: mirage: command not found
>> root@softbuild:~# opam reinstall mirage
>> [ERROR] mirage is not installed.
>>
>> 'opam reinstall mirage' failed.
>> root@softbuild:~# opam install mirage
>> root@softbuild:~# mirage
>> -bash: mirage: command not found
>> root@softbuild:~# opam reinstall mirage
>> [ERROR] mirage is not installed.
>>
>> Installing "aspcud" sorted it all out (and makes it faster!).
>
> Aspects is pretty much a necessity in opam 1.1.1; most packaging marks it as 
> recommended now. Hopefully Thomas can fix the internal solver in 1.2 with 
> some more heuristic magic :-)

Sounds good. The odd thing is that it didn't report any error, despite
(I presume) deciding not to install the program I asked for.

> The recompile came from the libraries that the mirage tool needs being 
> recompiled due to a depopt, being uninstalled during that, and then error 
> recovery not kicking (possibly broken solver)
>
> This is much improved in opam 1.2, and using Thomas' Makefile generator 
> instead of directly calling opam will help the user control when the package 
> installation happens.
>
>> - I was using the system ocaml, which lacked ocamlopt.opt, slowing
>> down the builds. Using "opam sw 4.01.0" sorted that out.
>
> Did you install the ocaml-native-compilers package?

Ah, that would explain it!

>> - mirage-console's install rule has some problems at the moment. Use
>> "ocamlfind remove" to remove the various bits manually and try again
>> if it happens.
>>
>> https://github.com/mirage/mirage-console/issues/17
>>
>> - direct_stackv4_with_default_ipv4 is a bit annoying. It contains an
>> IP address hard-coded into mirage, but it makes it difficult to see
>> how to change it for your own network. It might be better to use
>> direct_stackv4_with_static_ipv4 for the examples.
>
> Yeah, feel free to normalise any of these example and send a pull req btw. 
> They do need a spring clean (Mort and I will look at this soon for our ECOOP 
> tutorial at any rate)


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