Quoting Eric Blake (2015-09-03 15:50:16) > On 09/03/2015 08:30 AM, Markus Armbruster wrote: > > qapi/introspect.json defines the introspection schema. It's designed > > for QMP introspection, but should do for similar uses, such as QGA. > > [review to follow in separate message; I'm using this message to focus > on one point for easier tracking of the sub-thread] > > > > > The introspection schema does not reflect all the rules and > > restrictions that apply to QAPI schemata. A valid QAPI schema has an > > introspection value conforming to the introspection schema, but the > > converse is not true. > > > > Introspection lowers away a number of schema details, and makes > > implicit things explicit: > > > > * The built-in types are declared with their JSON type. > > > > TODO Should we map all the integer types to just int? > > So, given the discussion on v3, I think we will have consensus if v5 > does the following: > > - Merge 30 and 31 into a single patch, and drop this TODO statement (I > think we have agreement that exposing QMP [that is, JSON number] wire > form, with no additional constraints, as a single 'int', rather than the > underlying generated C types, is the way to go), provided that... > - Document in the qapi side that the schema intentionally lacks details > on ranges, and that consulting the qapi and/or C code may be required to > see what actual values are valid anywhere introspection merely says 'int', > - leave 32 as a separate patch, as it is complex enough, and still may > have debate on whether the types '123' and 'int' should have > corresponding array types '[123]' and '[int]' rather than the v3 patch > munging of '456' and '789' (I haven't yet reviewed whether v4 changed that).
Agreed on all 3 > > Any further arguments on whether exposing just 'int' in the > introspection for all integral types, and/or whether patches 30 and 31 > should be merged, are best made in response to this mail. Given the above, I don't think I have any further objections. > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
