Re: [XEN PATCH] libxl_nocpuid.c: fix build with json-c

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.11.2025 22:09, Michael Young wrote:
> The build of xen-4.21.0 with json-c present and yajl not present
> is failing with the error
> 
> libxl_nocpuid.c:43:1: error: unknown type name ‘yajl_gen_status’
>     43 | yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>        | ^~~~~~~~~~~~~~~
> libxl_nocpuid.c:43:50: error: unknown type name ‘yajl_gen’
>     43 | yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>        |                                                  ^~~~~~~~
> make[6]: *** 
> [/builddir/build/BUILD/xen-4.21.0-build/xen-4.21.0/tools/libs/light/../../../tools/Rules.mk:178:
>  libxl_nocpuid.o] Error 1
> 
> I tested it with the patch below based on libxl_nocpuid.c which did build.
> 
> Signed-off-by: Michael Young <m.a.young@xxxxxxxxxxxx>
> ---
>   tools/libs/light/libxl_nocpuid.c | 13 +++++++++++++
>   1 file changed, 13 insertions(+)
> 
> diff --git a/tools/libs/light/libxl_nocpuid.c 
> b/tools/libs/light/libxl_nocpuid.c
> index 0630959e76..71ab49ed61 100644
> --- a/tools/libs/light/libxl_nocpuid.c
> +++ b/tools/libs/light/libxl_nocpuid.c
> @@ -40,11 +40,24 @@ int libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t 
> domid, bool restore,
>       return 0;
>   }
> 
> +#ifdef HAVE_LIBJSONC
> +#ifndef _hidden
> +#define _hidden
> +#endif

Why would this be needed? libxl_internal provides a definition afaics.

> +_hidden int libxl_cpuid_policy_list_gen_jso(json_object **jso_r,

Nor should the attribute be needed here, as the function declaration ought
to be in scope.

> +                                libxl_cpuid_policy_list *pcpuid)
> +{
> +    return 0;
> +}
> +#endif
> +
> +#if defined(HAVE_LIBYAJL)
>   yajl_gen_status libxl_cpuid_policy_list_gen_json(yajl_gen hand,
>                                   libxl_cpuid_policy_list *pcpuid)
>   {
>       return 0;
>   }
> +#endif

Maybe unrelated to this build fix, I find it hard to believe that returning
0 (presumably meaning "success") here is appropriate without actually doing
anything. In particular for the new function you add, I think upon success
the caller can expect *jso_r to have got assigned a value. However, without
any commentary it's hard to tell whether there's some "agreement" that the
caller has to pre-set its variable (to, say, NULL).

Also why are the libxl_..._jso() all hidden, while their libxl_..._json()
counterparts aren't? And why would non-exported functions have their
declarations live in a non-private header?

Jan