The opam file advertises ISC as license, but some files - e.g. main.ml - include a LGPL 2.1 with static linking exception header.

In the meantime (June 2018, lwt 4.1.0, ocsigen/lwt#560) lwt was relicensed to MIT. I'd propose the folliowing:

• update the copyright statement in main.ml to reflect lwt 4.1.0 license
• figure out how compatible ISC and MIT are -- eventually it makes sense to relicense mirage-solo5 as MIT?

While checking the documentation of MirageOS, more precisely the tutorial Hello MirageOS World, at the end of Step 1, I encountered an unexpected behaviour of the command-line parsing for the Solo5 backend.
Namely, if I do:
mirage configure -t hvt
make depend
make
./solo5-hvt -- hello.hvt --hello="simple test",
then I get the following error message:
[...]
hello: too many arguments, don't know what to do with "test"
[...].
It seems to be the cases for all inputs containing at least one white space.
However, it is not the case when I execute the equivalent commands for a Unix backend.
Moreover, it is not the case if the input is set as default value:
mirage configure -t hvt --hello="simple test",
then everything works fine.
I am using opam 2.0.0, mirage 3.2.0, mirage-solo5 0.4.0.

This concerns the following packages:

• mirage-block-solo5
• mirage-bootvar-solo5
• mirage-console-solo5
• mirage-net-solo5
• mirage-solo5 (@hannesm #58)

Notably, ocaml-freestanding and Solo5 itself (solo5-bindings-*) are not in scope here as these use a Makefile-based build system and Solo5 itself should not depend on any OCaml tooling.

This will allow easier iteration (starting with vendoring) on barriers and discard which Wodan needs.

@pascutto has already ported mirage-block-solo5.
As @mato points out, we should keep a single build system for Solo5, so port the other device packages as well as mirage-solo5 itself.

Running the speaking_clock example from mirage-skeleton fails on my freshly-installed alpine-3.6.1 machine with mprotect:...EACCES according to strace.

The binary successfully

• opens /dev/kvm
• opens speaking_clock.ukvm
• reads the ELF contents from speaking_clock.ukvm
• fails the mprotect

This is with v0.2.1 of mirage-solo5 if that's relevant.

Cstruct buffers may be slices of larger buffers and in this case it is not sufficient to pass just the pointer to the buffer and length to a C stub, but the internal offset into the buffer must also be passed.

The following C stubs which accept a Cstruct buffer all suffer from the same issue, initially discovered during the Marrakesh retreat:

• mirage_solo5_block_read, mirage_solo5_block_write
• mirage_solo5_net_read, mirage_solo5_net_write

This has not been a problem until now, since the network stack (mirage-tcpip) does not use slices, and no one has exercised the block code beyond the simple test in mirage-skeleton which does not do this either. With the availability of Wodan this changes, so at least the block stubs and mirage-block-solo5 need to be updated. Given that this requires an incompatible interface change, I will also update the network stubs and mirage-net-solo5 for consistency and future-proofing.

/cc @hannesm @g2p