Re: [libvirt] [PATCH v2 4/4] libxl: Add a test suite for libxl option generator
On Mon, 2014-06-16 at 17:11 -0600, Jim Fehlig wrote:
This function exists in Xen 4.2 as well, in libxl.h.
Any ideas on how to handle this? I'm not aware of an existing macro to check for func 'foo' defined in header 'bar'. Is writing a custom macro along these lines a good solution? A bad solution I tried was hacking the test to check libxl version via libxl_get_version_info(), but that API does not work if not running Xen.
From the PoV of these tests (or any application generally) I'd have
Given that it exists in everything from 4.2 onwards why do you need to check for it? thought you wouldn't really care if you get this function from libxl.h directly or indirectly via libxl.h including _libxl_types.h. Ian.
Ian Campbell wrote:
On Mon, 2014-06-16 at 17:11 -0600, Jim Fehlig wrote:
This function exists in Xen 4.2 as well, in libxl.h.
Any ideas on how to handle this? I'm not aware of an existing macro to check for func 'foo' defined in header 'bar'. Is writing a custom macro along these lines a good solution? A bad solution I tried was hacking the test to check libxl version via libxl_get_version_info(), but that API does not work if not running Xen.
Given that it exists in everything from 4.2 onwards why do you need to check for it?
Hrm, right. I had the half-brained idea to use this to solve the failures I saw when testing this series against Xen 4.2 https://www.redhat.com/archives/libvir-list/2014-June/msg00170.html I think the solution to that specific problem is to use Xen 4.2 config as the baseline. But it got me thinking about the general problem you mentioned near the end of this mail https://www.redhat.com/archives/libvir-list/2014-June/msg00032.html With virJSONStringCompare in 1/1, Daniel provides a way to handle existence of new fields showing up in the json. But what if I want to write a test where the expected data is not supported on earlier versions? E.g. how would I add a test to check conversion of '<tpm ...>' to 'vtpms: [ ]' and expect that to work when running 'make check' against a 4.2 libxl where vtpms were not yet supported? I suppose each such test would have to probe for the feature it checks and skip if not found. Regards, Jim
On Tue, 2014-06-17 at 12:40 -0600, Jim Fehlig wrote:
Ian Campbell wrote:
On Mon, 2014-06-16 at 17:11 -0600, Jim Fehlig wrote:
This function exists in Xen 4.2 as well, in libxl.h.
Any ideas on how to handle this? I'm not aware of an existing macro to check for func 'foo' defined in header 'bar'. Is writing a custom macro along these lines a good solution? A bad solution I tried was hacking the test to check libxl version via libxl_get_version_info(), but that API does not work if not running Xen.
Given that it exists in everything from 4.2 onwards why do you need to check for it?
Hrm, right. I had the half-brained idea to use this to solve the failures I saw when testing this series against Xen 4.2
https://www.redhat.com/archives/libvir-list/2014-June/msg00170.html
I think the solution to that specific problem is to use Xen 4.2 config as the baseline. But it got me thinking about the general problem you mentioned near the end of this mail
https://www.redhat.com/archives/libvir-list/2014-June/msg00032.html
With virJSONStringCompare in 1/1, Daniel provides a way to handle existence of new fields showing up in the json. But what if I want to write a test where the expected data is not supported on earlier versions? E.g. how would I add a test to check conversion of '<tpm ...>' to 'vtpms: [ ]' and expect that to work when running 'make check' against a 4.2 libxl where vtpms were not yet supported? I suppose each such test would have to probe for the feature it checks and skip if not found.
Right. You'd probably want to gate such a test case on the corresponding LIBXL_HAVE_XXX #define from libxl.h. Ian.
On Tue, Jun 17, 2014 at 12:40:30PM -0600, Jim Fehlig wrote:
Ian Campbell wrote:
On Mon, 2014-06-16 at 17:11 -0600, Jim Fehlig wrote:
This function exists in Xen 4.2 as well, in libxl.h.
Any ideas on how to handle this? I'm not aware of an existing macro to check for func 'foo' defined in header 'bar'. Is writing a custom macro along these lines a good solution? A bad solution I tried was hacking the test to check libxl version via libxl_get_version_info(), but that API does not work if not running Xen.
Given that it exists in everything from 4.2 onwards why do you need to check for it?
Hrm, right. I had the half-brained idea to use this to solve the failures I saw when testing this series against Xen 4.2
https://www.redhat.com/archives/libvir-list/2014-June/msg00170.html
I think the solution to that specific problem is to use Xen 4.2 config as the baseline. But it got me thinking about the general problem you mentioned near the end of this mail
https://www.redhat.com/archives/libvir-list/2014-June/msg00032.html
With virJSONStringCompare in 1/1, Daniel provides a way to handle existence of new fields showing up in the json. But what if I want to write a test where the expected data is not supported on earlier versions? E.g. how would I add a test to check conversion of '<tpm ...>' to 'vtpms: [ ]' and expect that to work when running 'make check' against a 4.2 libxl where vtpms were not yet supported? I suppose each such test would have to probe for the feature it checks and skip if not found.
My last approach was to allow the JSON comparator to skip certain types of missing data but I don't think that's sufficiently flexible anymore. I'm thinking instead, that we could maintain a set of context paths which designate things that are new in each version, which would indicate things that should be skipped with old versions. So we with 4.3, we'd list /c_info/driver_domain /c_info/pvh and any other newly added fields. Then when running the test on 4.2 if the expected XML contained either of those paths, we'd skip them when comparing against the actual JSON. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (3)
-
Daniel P. Berrange -
Ian Campbell -
Jim Fehlig