Hi, this is what we said at the meeting (2022-06-22) and we scheduled another meeting in 2 weeks (2022-07-06 14:00 - 15:00 (CEST)). Thanks for your participation. Sorry for my english and if I missed something, please tell us through this email :) ! Enjoy.
PS: I will let Hannes send another email to schedule the next meeting. # Mirage 2022-06-22 ## Presentation round reynir: I'm in robur :) pierre: I'm Pierre, CS teacher (in France, Bretagne), I recently joined MirageOS. I want to use it and teach new things to my students. thomas: continue to work on eio and OCaml 5 stuff. I plugged eio into lwt and async. It should be possible to plug into MirageOS timada: from Japan, working on Solo5 and microcontrollers, I finished implementing 40% percent of tenders. I look into details. ## What is going on about mirage romain: Hannes did a PR about reproducible builds and added few meta-informations into the generated OPAM files to let `orb` to build unikernels: https://github.com/mirage/mirage/pull/1335 Some works was done about `ocaml-solo5` (thx to Pierre and Hannes) to provides some metrics about allocations on the C heap (with `dlmalloc`): https://github.com/mirage/ocaml-solo5/pull/120 A release of `ocaml-solo5` was done and a pending PR exists about `mirage-xen` to be able to get these informations: https://github.com/mirage/mirage-xen/pull/48 All of that is related to some issues found about `qubes-firewall` and Solo5, you can see the CHANGES.md of Solo5 here: https://github.com/Solo5/solo5/pull/518 Waiting to merge the reproducible build PR on MirageOS 4 and be able to: 1) do a release of `mirage-xen` (which includes allocation metrics) 2) do a release of `mirage` with right bounds about `mirage-xen`/`ocaml-solo5` (because the API was updated) This release will be done probably in a few weeks. ## Job rounds ### Pierre round pierre: question about memory consumption and mirage-xen PR ( https://github.com/mirage/mirage-xen/pull/48) should we merge what we did on `mirage-xen` into `mirage-solo5` (because they use the same things, eg. solo5) romain: for me it's good to do pierre:I did an unikernel which implements a NAT router into the Tor network, https://github.com/palainp/torrefacteur thomas: it's like an unix gateway? pierre: I would like to replace the unix gateway by a VM, so yes be able to route some traffic on default gateway and route some traffic on tor thomas: will be a useful unikernel reynir: Hannes made a PR (https://github.com/mirage/ocaml-conduit/pull/414) into conduit which should fix the issue about the Tor unikernel pierre: I saw the fix but I'm not sure how to use this fix. I think I need to work on something on what Hannes wrote on this PR pierre: I also have a question. I wrote a code to work with ESP32 to be able to use it as a wifi card with the PPP protocol. Then, I can use this controller to process the wifi. I have a question about Gilbraltar (RPi4) which does not yet have a network. PPP interesting? timada: if you want to use TCP/IP with MirageOS on a micro-controller, you need to have both a TCP/IP handling layer on MirageOS and also basically a packet transmitting/receiving layer which is provided on the C layer. For instance, the packet transmitting/receiving layer is implemented by the Linux operating system for unix, seccomp. For a microcontroller, you must have something which handles that. romain: for RPi4, the difficulty is about the Ethernet driver which is missing from Gilbraltar. But if someone wants to implement the Ethernet driver, it's just a matter of plugging `mirage-tcpip` then and you have a full network stack. More concretely, you need to deal with *mbox* and interrupts to be able to implement the ethernet driver, a PR exists on Gilbraltar which handles interrupts from the CPU to the OCaml side ( https://github.com/dinosaure/gilbraltar/pull/19). From it, you should be able to implement an Ethernet driver in OCaml may be (with few C codes) timada: https://mcuxpresso.nxp.com/api_doc/dev/329/group__lpc__enet.html this is an ethernet driver target to bare-metal and it does not depends to highly complexe Linux things, it can be interesting. I think it's difficult to port the ethernet driver from Linux to bare-metal. romain: Yeah. the ethernet driver for RPi4 provided by Linux is too complex for us and require too many things but I found a bare-metal ethernet driver too in C++ (https://github.com/rsta2/circle/blob/master/lib/bcm54213.cpp) (BCM54213PE PHY). From a quick look, it should not be super difficult to implement it. timada: if we use a small microcontroller, in many cases the microcontroller provides something for ethernet/wifi. And you probably can use them. Like ESP32 provides that. ### Romain romain: try to implement a peer-to-peer file-transfer with a simple tool and a unikernel as a relay. Implement the protocol with SPAKE2+EE ( https://github.com/dinosaure/spoke) and the tool ( https://github.com/dinosaure/bob) # Thomas thomas: Look into the eio supports on MirageOS 4, I would like to upgrade mirage-skeleton with eio. Be able to use the direct-style on some of them. # Reynir reynir: Caldav code, otherwise I work on builder/reproducible build romain: maybe you can talk about caldav reynir: It's an unikernel which implements a CalDAV server with the CalDAV protocol. Git is used as the store. You can create users and multiple calendars. romain: we currently use it (4 peoples) to find some bugs by usage and improve it. # Timada timada: Solo5 on microcontrollers, I also need to understand the muen Solo5. Especially the muen framework. The new building framework is different from the previous one. Look into `ocaml-solo5`, `solo5` romain: yeah the new layout of Solo5 is about _toolchains_. Solo5 provides a new toolchain (like `cc`, `ld` and `objcopy`) which is a wrapper with a compiler (like `gcc` or `clang`) or a cross-compiler (like `aarch64-gcc`). Then, `ocaml-solo5` uses this C toolchain to compile the _caml runtime_ and provide a new OCaml _toolchain_. At the end, for the mirage tool and depending on what the user wants, we choose the right OCaml _toolchain_. timada: What about `opam monorepo`? romain: Yeah, it's mostly about (transitive?) dependencies which include C stubs. We must compile them with certain flags (like `-ffreestanding` or `-nostdlib`). These flags will be provided by the OCaml toolchain which use the correct C toolchain (the `cc`/`ld`/`objcopy` provided by Solo5 first). By this way, we compile everything needed by the unikernel into a coherent `dune`'s context. timada: I'm currently testing my test compilation with a very simple Makefile. It does not care about `opam-monorepo`. I will look into that. Le mer. 8 juin 2022 à 08:05, Hannes Mehnert <han...@mehnert.org> a écrit : > Hi, > > sorry I'm not able to make it today. So the next meeting will be in two > weeks, June 22nd 14:00 CEST (ics attached). I'll write a reminder before > that takes place. > > > Best, > > Hannes > > > On 27/05/2022 12:08, Hannes Mehnert wrote: > > The next meeting will be on June 8th at 14:00 CEST (again on > > https://whereby.com/ocamllabs). The agenda and minutes at > > https://pad.data.coop/jgZ3NnyETWaaIT-5FM8ceA# (ics attached) -- Romain Calascibetta - http://din.osau.re/
