MirageOS - parametric compilation depending on target

Ecosystem
12

Well done! I’m always happy to see constructive proofs that people other than the mirage devs can write devices. :stuck_out_tongue:

Thank you! :slight_smile:

What do you mean by “unify” here ? It seems to me like you are applying almost all your functors by hand, which is more or less what should be avoided.

For background information: The .t types in the Qubes modules are
used to store vchan handles
for communication with the operating system.

  • Functor applications: The problem is that I had to capture the
    Qubes.GUI.t handle in order to call
    Framebuffer(Framebuffer_qubes).init, and return that (as mentioned
    above).

This means I had to use the mirage configure -t xen target to avoid
the initialization of the qubesdb impl, and do the initialization
myself (arguably dirty, but not sure how to avoid that otherwise).

To avoid having to expose the Qubes.GUI.t type in the applied
Framebuffer functor I opted to initialize it and return a packed
module

I didn’t see any other obvious way to do it, but I’m open to other ideas :slight_smile:

  • Unification: My original idea was that I could somehow have one impl
    that depended on qubesdb so that I could receive the initialization
    handle.

EDIT: My post got cut off for some reason.

  • Having a target-specific store for global state (such as these handles), as you proposed above, would be much nicer. Especially if it was available to other impl’s.
    Unfortunately I have no idea how to implement this. :frowning:

  • Alternatively we could go for a more specific solution to the problem and store the initialized “state handles” in mutable fields in the QubesDB module, and expose mock implementations for targets that do not actually work with Qubes [instead of halting the compilation as the device currently does]. (@yomimono, @talex5, what do you think about this idea?)