Well done! I’m always happy to see constructive proofs that people other than the mirage devs can write devices.
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
This means I had to use the
mirage configure -t xen target to avoid
the initialization of the
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
I didn’t see any other obvious way to do it, but I’m open to other ideas
- Unification: My original idea was that I could somehow have one
that depended on
qubesdb so that I could receive the initialization
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
Unfortunately I have no idea how to implement this.
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?)