Re: [Xen-devel] [PATCH V4 09/24] libxl_json: introduce parser functions for builtin types

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-05-13 at 12:40 +0100, Wei Liu wrote:
> On Tue, May 13, 2014 at 12:28:42PM +0100, Anthony PERARD wrote:
> > On Tue, May 13, 2014 at 12:03:59PM +0100, Wei Liu wrote:
> > > On Tue, May 13, 2014 at 11:55:30AM +0100, Ian Campbell wrote:
> > > [...]
> > > > > And presumably if we are to make this change we also need to update
> > > > > libxl.h to have LIBXL_JSON_GENERATE_NUMBER-ish? What would you suggest
> > > > > for the name?
> > > > 
> > > > Does this actually change the output syntax at all? If it is just a bug
> > > > fix then we don't need to announce it I think. Any consumers of the JSON
> > > > will have to cope with the buggy version (if they want to) irrespective
> > > > of any #define.
> > > > 
> > > 
> > > I will need to check. Presumably it generates a string or something.
> > > 
> > > We can treat it as a bug fix if we only use yajl_gen_number of uint64_t,
> > > other uint types are not affect.
> > 
> > >From the JSON format perspective, every numbers are signed decimal, I
> > think (after a quick look on wikipedia). The parser may make a difference
> > between signed/unsigned decimal/interger.
> > 
> > For the default value, it might make sense to not include them, since
> > there are basicly not set values.
> > 
> 
> Can you confirm that the existing consumer (QEMU?) will not care if those
> values are absent in JSON object? If QEMU uses our parser then it should
> be fine.

The objects passed to qemu are not libxl IDL/autogenerated ones, are
they? They are RPC calls which are crafted via some other mechanism.

IOW I don't think this change is going to impact those at all.

Ian.


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