On 27/08/2025 6:51 pm, Jason Andryuk wrote: > On 2025-08-08 10:55, Anthony PERARD wrote: >> From: Anthony PERARD <[email protected]> >> >> - libxl changes: >> >> While doing so, we rename all "*_gen_json" function to "*_gen_jso" as >> they have different prototype. All the function pointer are been cast >> to (libxl__gen_json_callback) by "gentypes.py" when generating >> "*_to_json()" functions. >> >> We also introduce a few more "*_gen_jso" functions for "int" and >> "bool" because we can't use json_object_*() functions from json-c >> directly like it's done with yajl. >> >> To make the generation of _libxl_types*json.[ch] with both YAJL and >> json-c we add "--libjsonc" to gentypes.py so it can generate >> functions/types for both. >> >> Also introducing "jsonc_json_gen_fn" in the IDL, to be able to point >> to a different function when using json-c. >> >> Also, don't export any of the new *_gen_jso() function, at the cost of >> having "_hidden" macro in semi-public headers. >> >> - xl changes: >> >> Also, rework the implementation of printf_info() in `xl` to avoid >> using libxl_domain_config_gen_json() which isn't available without >> YAJL. The implementation using "json_object" call >> libxl_domain_config_to_json() which generate a plain string of JSON, >> which we parse to add it to our own json; this avoid a dependency on >> the json library used by libxl. >> >> Signed-off-by: Anthony PERARD <[email protected]> > >> @@ -358,6 +535,36 @@ int libxl__mac_parse_json(libxl__gc *gc, const >> libxl__json_object *o, >> return libxl__parse_mac(libxl__json_object_get_string(o), *p); >> } >> +#ifdef HAVE_LIBJSONC >> +int libxl_hwcap_gen_jso(json_object **jso_r, libxl_hwcap *p) >> +{ >> + json_object *jso; >> + int i; >> + int rc = ERROR_FAIL; >> + >> + jso = json_object_new_array(); >> + if (!jso) goto out; >> + >> + for(i=0; i<4; i++) { > > typedef uint32_t libxl_hwcap[8]; > > I see this is the same as the yajl implementation, but should this be 8? > > The remainder looks good: > > Reviewed-by: Jason Andryuk <[email protected]>
A tangent, but physinfo.hw_cap (which libxl_hwcap wraps) is as good as stack rubble. It's not exactly random data, but it is a view of an internal Xen structure which has been reformatted multiple times before we even realised it was exported, then continued being reformatting it because it's a gross laying violation that noone could possibly be using anyway. It needs purging from libxl and the sysctl interface, and if that makes JSON easier, then lets get it done. ~Andrew
