Re: [PATCH v2 03/31] qapi/qom: Add ObjectOptions for iothread

[Kevin Wolf <kwolf@redhat.com>]

Am 25.02.2021 um 23:55 hat Eric Blake geschrieben:
> On 2/24/21 7:52 AM, Kevin Wolf wrote:
> > Add an ObjectOptions union that will eventually describe the options of
> > all user creatable object types. As unions can't exist without any
> > branches, also add the first object type.
> > 
> > This adds a QAPI schema for the properties of the iothread object.
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >  qapi/qom.json | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 53 insertions(+)
> > 
> > diff --git a/qapi/qom.json b/qapi/qom.json
> > index 96c91c1faf..bf2ecb34be 100644
> > --- a/qapi/qom.json
> > +++ b/qapi/qom.json
> > @@ -202,6 +202,59 @@
> >    'returns': [ 'ObjectPropertyInfo' ],
> >    'allow-preconfig': true }
> >  
> > +##
> > +# @IothreadProperties:
> > +#
> > +# Properties for iothread objects.
> > +#
> > +# @poll-max-ns: the maximum number of nanoseconds to busy wait for events.
> > +#               0 means polling is disabled (default: 32768 on POSIX hosts,
> > +#               0 otherwise)
> > +#
> > +# @poll-grow: the multiplier used to increase the polling time when the
> > +#             algorithm detects it is missing events due to not polling long
> > +#             enough. 0 selects a default behaviour (default: 0)
> > +#
> > +# @poll-shrink: the divisor used to decrease the polling time when the
> > +#               algorithm detects it is spending too long polling without
> > +#               encountering events. 0 selects a default behaviour (default: 0)
> 
> Matches PollParamInfo declarations in iothread.c.
> 
> > +#
> > +# Since: 2.0
> 
> How did you determine this value?  (I'm not questioning it being
> something other than 6.0, because we have indeed supported QMP
> configuration of these values via the untyped magic previously present
> in add-object).

I had 6.0 in v1 of the series, but Paolo requested that I make it the
version when the object was introduced (which is arguably the more
useful information to provice), so that's what I did.

In simple cases like here, the object type was introduced together with
a new source file. In these cases it was 'git log iothread.c', finding
the first commit and then 'git describe --contains $COMMIT'. In more
complex cases basically the same, except that finding the right commit
was sometimes a little bit harder and may have involved 'git blame'.

> > +##
> > +{ 'struct': 'IothreadProperties',
> > +  'data': { '*poll-max-ns': 'int',
> > +            '*poll-grow': 'int',
> > +            '*poll-shrink': 'int' } }
> 
> These are correctly typed per the code in iothread.c, but it does raise
> the question of whether a signed 64-bit value is the best choice, or if
> we might later want to revisit things to pick more constrained types.  I
> don't think such an audit should hold up this series, though.

Yes, I'm just representing in the schema what is already there in the
code.

Kevin