Modular build for ukvm #5
Conversation
| let pkg_config_deps = "mirage-solo5 ocaml-freestanding" in | ||
| append fmt "\tpkg-config --print-errors --exists %s" pkg_config_deps; | ||
| append fmt "\tld $$(pkg-config --variable=ldflags solo5-kernel-ukvm) \\\n\ | ||
| >>= fun extra_c_archives -> |
There was a problem hiding this comment.
I don't think this comment is specific to your change. But won't it be very hard to touch this mirage file when it gets upstreamed? wouldn't it be better to move this solo5 logic to some solo5 specific repo (somehow)?
There was a problem hiding this comment.
@ricarkol The Solo5 changes to the mirage frontend tool follow the same structure as the other targets. For example, lib/mirage.ml contains Xen-specific code. We can still change things after upstreaming, it'll just be more (administrative) work. (See yesterday's long discussion on releases and dependencies in #solo5 on Slack.)
There was a problem hiding this comment.
@ricarkol: we can cut mirage tool point releases pretty fast if something changes unexpectedly in the solo5 packaging
There was a problem hiding this comment.
Thanks for the answers.
I was asking mainly because I'm planning to submit a PR to have something similar at the kernel level: if there is no disk, then no disk related code should be built for the kernel image. But that should wait until you come back, and after we have the discussion related to the devices abstraction.
|
Solo5/solo5#64 has been merged, so I'm merging this also. |
This PR should be considered with the matching one in solo5/solo5. (Solo5/solo5#64)
The generated Makefile will now invoke
ukvm-configureto output a specializedukvm-binbinary that can be used to run the unikernel whenukvmis chosen as the backend. Which modulesukvm-binis compiled with is determined by thelibsvariable, ultimately coming from Functoria.