On Mon, Nov 14, 2022 at 08:53:17AM -0700, Jim Fehlig wrote: > On 11/14/22 01:18, Jan Beulich wrote: > > On 14.11.2022 07:43, Henry Wang wrote: > > > Sorry, missed Anthony (The toolstack maintainer). Also added him > > > to this thread. > > > > Indeed there's nothing x86-ish in here, it's all about data representation. > > It merely happens to be (for now) x86-specific data which is being dealt > > with. > > > > Internally I indicated to Jim that the way the code presently is generated > > it looks to me as if 0 was simply taken as the default for "pnode". What I > > don't know at all is whether the concept of any kind of default is actually > > valid in json representation of guest configs. > > 0 is definitely ignored in the generated libxl_vnode_info_gen_json() > function, which essentially has > > if (p->pnode) > format-json > > I took a quick peek at the generator, but being totally unfamiliar could not > spot a fix. I'm also not sure how such a fix could be detected for testing > purposes by libxl users like libvirt. I.e. how to detect a libxl that emits > `"pnode:" 0` in the json representation of libxl_domain_config object and > one that does not.
Well, the missing "pnode: 0' in json isn't exactly a bug, it's been done on purpose, see https://xenbits.xen.org/gitweb/?p=xen.git;h=731233d64f6a7602c1ca297f7b67ec254 When the JSON is been reloaded into it's original struct, libxl_vnode_info, pnode will have the expected value, that is 0, because libxl_vnode_info_init() would have reset this field to 0. I don't think it's possible to change the generator to just have it generate '"pnode": 0', as if we make a change, it would have to be for all unsigned it, I think. Is it actually wanted to have all those in json, or is it just a case of looking like there's missing part? Also, I don't know if any part of libxl rely of this behavior, that is where default values are omitted from json output. Thanks, -- Anthony PERARD
