Re: [libvirt] [PATCH V2 5/6] xenconfig: support bios=ovmf xl.cfg

On 09.06.2016 19:06, Jim Fehlig wrote: > > You bring up a point here that I'm not quite sure how to handle. > LIBXL_FIRMWARE_DIR can certainly be different between Xen installations, > depending on configuration options selected when building Xen. But currently all > the various data files under tests/ are "hard-coded". E.g. > tests/xlconfigdata/test-fullvirt-ovmf.xml introduced in this patch contains > > <loader readonly='yes' type='pflash'>/usr/lib/xen/boot/ovmf.bin</loader> > > but it should really contain > > <loader readonly='yes' type='pflash'>LIBXL_FIRMWARE_DIR/ovmf.bin</loader> Yes. this is what I had in mind, thank you for writing it down. > How should test data files which depend on values discovered at build time be > handled? Good question. I don't think we have such case in our test suite yet. So it's up to us to walk the path for others :) > Should they be created at build time from e.g. > tests/xlconfigdata/test-fullvirt-ovmf.xml.in? Not a bad idea. This will definitely work thus it can be our fall back if other approaches fail. > Is there a better trick for > substituting values discovered at build time in test data files? Well, I'm thinking of fixing the path in the testsuite. In xlconfigtest depending on mode either testCompareParseXML or testCompareFormatXML is called. For the simplicity of explanation assume just the former one, the latter would be similar. In the testCompareParseXML, the domain XML is parsed and xl config is then produced from it. What if we introduced a boolean that if set would mangle^Wfix the boot loader path just before we try to produce xl config from it? Then, testCompareHelper would merely just pass the boolean from testInfo struct. Thus we would need new macro, say DO_TEST_FIX_LOADER (I know, terrible name) which would set the boolean in the struct. All other macros would then leave the boolean unset (=false). I know this is not a terrific idea, because if one would open the XML, the corresponding config would not be its exact copy. Or even better, in the XML there would be <loader>LIBXL_FIRMWARE_DIR/ovmf.bin</loader> and if the boolean is set, it would just replace LIBXL_FIRMWARE_DIR with the actual value of the macro (virStringReplace).

This way it would be obvious even in the XML that some post processing is happening in the test.