Re: [Xen-devel] [PATCH 5/5] Add a test suite for libxl option generator

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-05-30 at 18:24 +0100, Daniel P. Berrange wrote:
> +    if (STRNEQ(expectargv, (char *)actualargv)) {
> +        virtTestDifference(stderr, expectargv, (char *)actualargv);
> +        goto cleanup;
> +    }

Since you are using libxl_domain_config_gen_json you can control the
pretty printing, but if you were to use the libxl_domain_config_to_json
you might have problems if the library was to do something slightly
different e.g. with whitespace.

In 4.5 we will have libxl_*_from_json and (I think) libxl_*_compare, so
you could read in the template and compare it with the generated struct.
That doesn't help you now of course.

Also in 4.5 the json will omit fields which are set to the their
explicit default value. libxl_*_from_json will still do the right thing,
but it'd be another annoyance for you here I think.

Lastly, when we add new fields to the API they will start showing up in
the json (modulo the omission of defaults discussed above).

Other than having a template per libxl version (yuck) I don't have any
particularly smart suggestions except for to aim long
term for:
  libxl_domain_config_init(..., &template)
  libxl_domain_config_from_json(..., &template, "{ json json json ....")

  libxl_domain_config_init(..., &xml)
  virtLibxlFromXML(..., &xml, "<domain>....")

  libxl_domain_config_compare(&template, &xml)

which will likely handle all of those corner cases, except perhaps the
case where libvirt is using new fields on new versions of libxl etc. I
suppose that would be handled by specific unit tests for >= and <
versions of libxl separately?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel