Re: [MirageOS-devel] MirageOS Windows / Hyper-V Development

[Stephen Mack <smack815@xxxxxxxxx>]

Anil,

Doesn't Mirage depend on the Jane Street Core which has not yet been ported to Windows? Or maybe I am mistaken.

The more platforms that accept Mirage the better in my opinion.

Cheers

--Stephen

On Mon, Sep 22, 2014 at 5:10 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

On 19 Sep 2014, at 22:41, Brian Gianforcaro <b.gianfo@xxxxxxxxx> wrote:

Hello All,

I'm interested in working on adding support for Windows and eventually Hyper-V deployment of MirageOS unikernels.

My end goal is getting MirageOS unikernels running on Windows Azure, as it would seem having ubiquitous
cloud hosting support would be very valuable to the project. For now it seems like having just plain Windows process
support would be a great stepping stone to this eventual goal.Â

Hi Brian,

Glad to hear you're interested in working on this! Windows support has been oft-asked for, but noone's explicitly started doing anything in this direction yet.

One approach for Azure support that's been pointed out a few times is adding UEFI bootloader support; seeÂhttps://github.com/mirage/mirage/issues/187

However, it would certainly be easier to start with good userspace support before delving into the kernel mode.

I've been poking around the code, and see that everything seems to be partitioned cleanly into separate packages for

xen and unix support. This gives me at least a little hope that windows / hyper-v support could be added piecemealÂ

overtime without being a merging nightmare as development continues to occur.

Very impressed with the clean isolation :)

As far as I can tell it seems like I would have to implement the following opam packages to get windows process support working:

 1) mirage-win        ÂMirage OS library for Windows compilation
 2) mirage-console-win  A Mirage-compatible Console library for Windows
 3) mirage-clock-win    A Mirage-compatible Clock library for Windows
 4) mirage-entropy-win  Mirage entropy device for Windows
 5) mirage-block-win    Mirage block driver for Windows
 6) mirage-fs-win      ÂMirage file system pass through driver for Windows
 7) mirage-net-win     ÂEthernet network driver for Mirage (seems like this might be optional?)
 8) mirage-tcpip-win    Userlevel TCP/IP stack
 9) mirage-http-win     Mirage HTTP client and server driver for Windows

The root mirage package 'mirage' would also have to be modified to support a --win option, and other plumbing.Â

Conceptually this all seems fine and dandy, be it a reasonably large chunk of work.Â

I'm not intimately familiar with the ocaml ecosystem on windows, I've only ever dabbled in the language
on unix machines. This leads be to wonder if Windows support for MirageOS is dead on arrival, given the
current windows support the tooling MirageOS fundamentally uses. For instance it seems like currently
even opam doesn't support running on windows? (I read that it is coming..) I imagine there are many
other such cases, that I simply won't know about until I hit them.

Am I mistaken, or is windows support for the tooling going to be a big blocker to getting anything working?

This is exactly the right analysis -- the package breakup is correct, but the existing approach to doing build will make things hard to compile on Windows, I suspect. However, we are working on a package description system called Assemblage [1] (lead by Thomas Gazagnaire and Daniel Buenzli) that should simplify build of Mirage packages considerably. The current interface is being revved and isn't finalised, but it should be fairly simple to ensure that the Makefiles that it generates are Windows compliant.

Which leads onto the second point -- it would be very useful to establish an absolute minimal set of libraries to get started with having a Windows environment on which to build upon. For Mirage, this is just the hello world example with mirage-win and mirage-console-win (and possibly the clock). Getting these ported requires selecting the preferred toolchain (mingw, Cygwin, MSVC?) and ensuring that OCaml itself is happy with the setup.

Once a console port works, the rest is just a matter of filling in the library blanks, just as we did over the years with the existing *nix and Xen backends.

[1] https://github.com/samoht/assemblage

best,

Anil

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

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