TL;DR: I’m currently developing MirageOS packages to support some QEMU devices and this work cannot align with the usual mirage-$device-$target convention, as QEMU works with several targets (one of which being virtio, which also supports non-QEMU hosts). I’m wondering the proper naming I should adopt.
I also have a few other questions for which I’d love some MirageOS gurus’ feedback.
Hi everyone,
I’m trying to have a bit more integration between QEMU and MirageOS for a new project of mine currently tied to QEMU, and one of the goals is to support a few devices exposed by QEMU that aren’t currently handled by MirageOS:
- Screens
- ACPI tables
- SMBIOS tables
- Keyboard and mouse interrupts (haven’t really looked at it yet)
- and a few other things
I’m currently working on the first item, screens, and have a working implementation for ramfb devices on x86_64, an almost-working implementation of VGA text mode for virtio-vga, and a rough WIP for 2D graphics for virtio-vga/virtio-gpu.
Now, this works well for what I want, namely QEMU+KVM virtualization on x86_64 hosts, on both virtio and unikraft-qemu targets, but I don’t know how to call my packages without breaking the de-facto naming convention too much (the goal is obviously to publish everything on OPAM).
The question gets broader quite quickly, as ramfb devices require the QEMU machine to expose a fw_cfg device, for which I also had to write a driver, and common low-level buffer and DMA management primitives, which also need a lovely package name. As “works on QEMU on x86_64” doesn’t really map onto a definitive (list of) target(s) for MirageOS, I’d like some feedback regarding the naming convention that I should adopt.
Additionally, I’d like to know if I can configure constants in my C stubs files directly from Mirage parameters (I’m allocating chunks of memory statically, but I’d like to be able to customize their sizes).
Finally, I have defined in a module a few helpers to easily be able to write screen @-> job and main $ screen_of_ramfb ~width ~height (), but for the compiler to actually be able to open this module, I had to override dune.config to add its package. Is it the proper way to expose new primitives to config.ml?
As a bonus question, I’m getting Solo5: PCI:00:02: unknown virtio device (0x1100) with my virtio-vga tests; is there any plan to let Solo5 know that the device is handled, to silence this message? (similar question for Unikraft)
Thanks a lot for your interest, and I hope to publish all of that really soon!