10:22 <ehirdoy> Hi experts, would it be possible to give some hint for how much effort is needed to run MirageOS on 32bit ARM?

10:24 <ehirdoy> I tried to run machine learning inference on MirageOS for IoT and some of popular IoT microcontrollers are 32bit ARM.

10:38 <hannes> ehirdoy: it (well, the Xen backend) (at least) used to run on arm32 (esp. cubieboard). there's also a prototypical port to esp32 by lucas https://www.lortex.org/posts/mirage/esp32/2018/10/02/what-now.html

10:38 <hannes> there's no (and not planned afaik) support for solo5 on 32bit. the arm32+xen port may suffer a bit from bitrot.

10:40 <ehirdoy> @hannes I may replace solo5 API with RTOS function call so that running it on 32bit ARM may be easier, skipping hypervisor?

10:41 <ehirdoy> well, not replacing but implementing solo5 API backend with RTOS function call?

10:42 <ehirdoy> 32bit ARM is needed since 64bit ARM doesn't make much sense for IoT ML inference :)

10:44 <hannes> ehirdoy iiuc this https://github.com/well-typed-lightbulbs/ocaml-baremetal-esp32 uses the approach (together with https://github.com/TheLortex/ocaml-freestanding/commit/9735c425be4313c7dd450841669046a1248bd52e and https://github.com/well-typed-lightbulbs/mirage-esp32))

10:46 <hannes> ehirdoy: so my rough approach would be to not think too much about solo5, but rather about mirage-solo5 (which implements the main event loop etc.) and ocaml-freestanding (providing the ocaml runtime) -- these are the only users of the solo5 API, so if you adapt these pieces to use <whatever-else-is-on-arm32> you won't need the solo5 api

10:47 <ehirdoy> are those ESP32 port natively compiled or bytecode?

10:47 <hannes> on a different note, you can run mirageos as unix/linux process on arm32 directly already (modulo bitrot)..

10:47 <hannes> this is a native port, with https://github.com/well-typed-lightbulbs/ocaml-esp32/ being the changes to the ocaml compiler (supporting esp32)

10:48 <ehirdoy> @hannes, so useful info!! Thanks!!

10:48 <hannes> in ocaml-freestanding, there's a single sysdeps_solo5.c, and there could be another sysdeps_arm32.c to be used on arm32..

10:48 <ehirdoy> @hannes :)

10:50 <hannes> the esp32 port was an attempt at cross-compilation as well, which lead to further improvements of the mirage utility build story (there are various PRs in progress, but this has not yet been merged) --> the esp32-opam-repo with lots of opam packages with "-esp32" suffix is no longer needed AFAICT (but i have neither worked on the former nor on the latter)

10:50 <hannes> ehirdoy: as first step, i'd really recommend to try compiling mirage/unix (so mirage configure -t unix) on an arm32 (or emulator thereof), and see if this produces working binaries

12:53 <reynir> Hmm. My unikernel has a constraint mirage-xen < 4.0.0 and I don't understand why

12:54 <kuso> reynir: are you pinning down _anything_ right now?

12:54 <kuso> reynir: are you sure your opam is opam 2.x? did you opam update?

12:54 <hannes> reynir: mirage -- the tool -- generates opam files with lower _and_ upper bounds -- maybe it generates sth with mirage-xen < 4.0.0?

12:55 <reynir> Yes, it generates mirage-xen < 4.0.0, hannes

12:56 <hannes> reynir: there's "package ~min:"3.1.0" ~max:"4.0.0" "mirage-xen"" in mirage/lib/mirage.ml ...

12:56 <reynir> But I don't see why it's doing that

12:56 <reynir> Aha

12:56 <hannes> since we ended in sad situations where we broke everything for existing users

12:57 <reynir> Haha oh :(

12:57 <hannes> feel free to PR to mirage a change with an adjusted upper bound (now certainly, every now and then we forget to adjust the lower+upper bounds)

12:58 <hannes> (it has been generating upper bounds since nov 2018, mirage 3.3.0)

13:02 <reynir> My unikernel compiles fine with mirage-xen 4.0.1

13:03 <hannes> cool, i barely track mirage-xen changes (and thus don't know why the major bumped), but if its fine, as said, we can easily bump the upper bound in the mirage tool.

13:04 <reynir> The changelog says OS.Xen was renamed to OS_xen (modulo spelling), but I'm not using those directly

13:05 <hannes> that's fine then, the constraints in the mirage utility should only _not being adjusted_ if the initialisation (or linking/...) procedure changed ~> feel free to PR ~max:"5.0.0" :)

13:05 <reynir> OS.Xen --> Os_xen

13:06 <hannes> yes, a change i don't really understand tbh

13:13 <reynir> https://github.com/mirage/mirage/pull/995

13:14 <reynir> Thanks, hannes

13:14 <kuso> reynir: still something weird, i just ran a builder-build in a clean vm and it auto-picked 4.0.1 afaict

13:16 <hannes> (the constraint is only picked up on make depend // opam install --deps-only . ~~> a mirage build / make won't take up these constraints)

13:18 <reynir> Okay, qubes-mirage-firewall breaks on mirage-xen 4.0.1 -- OS.MM.Heap_pages.total is unbound

13:21 <kuso> reynir: 4.08.0 ?

13:21 <kuso> (for both)

13:23 <reynir> I think I had to downgrade to OCaml 4.07.0

13:24 <reynir> No wait, I could use OCaml 4.08.0 for the firewall, but not for the ssh-agent

13:24 <kuso> i upped it to 4.08.0 for the -fw in Makefile.builder recently, but ssh-agent still has 4.05.0 there, retry with both at 4.08.0 running right now.

13:30 <reynir> I think some dependency for ssh-agent doesn't work for 4.08.0 yet, but 4.07.1 works

13:31 <reynir> Also, I found out it's not just OS.Xen --> Os_xen, OS.Xs has also been renamed/moved to Os_xen.Xs...

13:32 <reynir> Aaand OS.MM --> Os_xen.MM

13:49 <kuso> (yes, ssh-agent with 4.08.0 explodes here too)