On 06/10/2016 01:47 AM, Michal Privoznik wrote: > 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). Ah, good idea. I'll give this a shot in V3. > > This way it would be obvious even in the XML that some post processing > is happening in the test. Right. And I should be able to precede it with a comment in the XML to make it even more clear. Thanks for the ideas! Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list