Addition of common code from unikernels?

[palainp]

Dear developpers,

Thinking about the code that can be factored between qubes-mirage-firewall and qubes-miragevpn (see https://github.com/robur-coop/qubes-miragevpn/issues/9), maybe the following can be written here:

• check_memory (this function allows, if called often enough, to run the unikernel with 32MB (or a bit less), this seems to be especially true if Ocaml5+ wants us to trigger the collections manually, but I'm not sure where I've read that :( )
• shutdown waits for the shutdown request and will be common to all Qubes unikernels

Something in lib/misc.ml like that?:

let check_memory () =
  let fraction_free stats =
    let { Xen_os.Memory.free_words; heap_words; _ } = stats in
    float free_words /. float heap_words
  in
  let stats = Xen_os.Memory.stat () in
  if fraction_free stats > 0.4 then `Ok
  else (
    Gc.full_major ();
    let stats = Xen_os.Memory.quick_stat () in
    if fraction_free stats < 0.4 then `Memory_critical
    else `Ok
  )

let shutdown =
  let* value = Xen_os.Lifecycle.await_shutdown_request () in
  match value with `Poweroff | `Reboot -> Lwt.return_unit in

Now, when I look into the previous unikernels, they wait for:

• wait_clients (in the case of network functions, the unikernel will have to accept clients' connexions). That function setup a condition triggered when qubesDB changes, creates a new interface for the communication with the new client plus adds a finalizer that waits for the client to disconnect, and defines a callback function that handles incoming packets.
• something like from_uplink which waits for uplink replies (DNS requests initiated by the unikernel, or replies to packets nated and transmitted for a client)
• and the firewall also adds the possibility for a netvm update

Defining these is probably more complex, and I'm not confident enough to make a proposal. To me, they should permit to define the callback function that have to handle the incoming packets (and activate or not the check_memory test). I'm unsure how to deal with the netvm update function so far. It really adds complexity to the code.

Thank you for any advice :)

[hannesm]

I've not looked to deep, but that sounds like a good plan (to have some sort of Common or Misc (or directly Mirage_qubes.shutdown etc.). I think that starting with the "simple" common functionality is the path forward, we can always add more functionality once the (desired) API is clear :)

About "Ocaml5+ wants us to trigger the collections manually", all I know is that compactions need to be done manually.

In respect to memory usage, the no-cstruct work should be much nicer for the GC and our hope is we have to do less manual calling Gc.full_major ().

[palainp]

This has been done in #71 :)