qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: marcandre.lureau@gmail.com, qemu-devel@nongnu.org,
	qemu-block@nongnu.org, armbru@redhat.com
Subject: Re: [PATCH 1/4] qapi: Add a 'coroutine' flag for commands
Date: Mon, 13 Jan 2020 11:46:44 +0100	[thread overview]
Message-ID: <20200113104644.GD5549@linux.fritz.box> (raw)
In-Reply-To: <947485af-1862-2834-7a0f-f8db811268d5@redhat.com>

Am 10.01.2020 um 20:00 hat Eric Blake geschrieben:
> On 1/9/20 12:35 PM, Kevin Wolf wrote:
> > This patch adds a new 'coroutine' flag to QMP command definitions that
> > tells the QMP dispatcher than the command handler is safe to be run in a
> 
> s/than/that/

Thanks. If this remains the only change, I hope Markus can fix it while
applying the patch.

> > coroutine.
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >   tests/qapi-schema/qapi-schema-test.json |  1 +
> >   docs/devel/qapi-code-gen.txt            |  4 ++++
> >   include/qapi/qmp/dispatch.h             |  1 +
> >   tests/test-qmp-cmds.c                   |  4 ++++
> >   scripts/qapi/commands.py                | 17 +++++++++++------
> >   scripts/qapi/doc.py                     |  2 +-
> >   scripts/qapi/expr.py                    |  4 ++--
> >   scripts/qapi/introspect.py              |  2 +-
> >   scripts/qapi/schema.py                  |  9 ++++++---
> >   tests/qapi-schema/qapi-schema-test.out  |  2 ++
> >   tests/qapi-schema/test-qapi.py          |  7 ++++---
> >   11 files changed, 37 insertions(+), 16 deletions(-)
> > 
> > diff --git a/tests/qapi-schema/qapi-schema-test.json b/tests/qapi-schema/qapi-schema-test.json
> > index 9abf175fe0..55f596dbaa 100644
> > --- a/tests/qapi-schema/qapi-schema-test.json
> > +++ b/tests/qapi-schema/qapi-schema-test.json
> > @@ -147,6 +147,7 @@
> >     'returns': 'UserDefTwo' }
> >   { 'command': 'cmd-success-response', 'data': {}, 'success-response': false }
> > +{ 'command': 'coroutine_cmd', 'data': {}, 'coroutine': true }
> 
> Not user-visible (it's the testsuite), but why not follow our naming
> convention of 'coroutine-cmd'?

I just copied and modified the simplest example from a few lines above:

    { 'command': 'user_def_cmd', 'data': {} }

The command names in the test schema seem to follow no particular style,
there are even some CamelCaseCommands. But if I have to respin, I can
change it.

> > +++ b/docs/devel/qapi-code-gen.txt
> > @@ -457,6 +457,7 @@ Syntax:
> >                   '*gen': false,
> >                   '*allow-oob': true,
> >                   '*allow-preconfig': true,
> > +                '*coroutine': true,
> >                   '*if': COND,
> >                   '*features': FEATURES }
> > @@ -581,6 +582,9 @@ before the machine is built.  It defaults to false.  For example:
> >   QMP is available before the machine is built only when QEMU was
> >   started with --preconfig.
> > +Member 'coroutine' tells the QMP dispatcher whether the command handler
> > +is safe to be run in a coroutine. It defaults to false.
> > +
> >   The optional 'if' member specifies a conditional.  See "Configuring
> 
> Maybe "The optional 'coroutine' member tells..." for symmetry with the next
> paragraph.

Starting with 'Member ...' seems to be what is done for most other
options. I phrased it this way specifically for consistency.

> > +++ b/scripts/qapi/commands.py
> > @@ -15,6 +15,7 @@ See the COPYING file in the top-level directory.
> >   from qapi.common import *
> >   from qapi.gen import QAPIGenCCode, QAPISchemaModularCVisitor, ifcontext
> > +from typing import List
> >   def gen_command_decl(name, arg_type, boxed, ret_type):
> > @@ -194,8 +195,9 @@ out:
> >       return ret
> > -def gen_register_command(name, success_response, allow_oob, allow_preconfig):
> > -    options = []
> > +def gen_register_command(name: str, success_response: bool, allow_oob: bool,
> > +                         allow_preconfig: bool, coroutine: bool) -> str:
> > +    options = [] # type: List[str]
> 
> Aha - now that we require python 3, you're going to exploit it ;)

Of course. :-)

I was hoping that I could get the type checker to tell me if I forgot to
change one of the callers, but that doesn't really work until we add
type annotations to the callers as well. I'm going to send a separate
series to do a little more about type checking.

> > +++ b/scripts/qapi/introspect.py
> > @@ -212,7 +212,7 @@ const QLitObject %(c_name)s = %(c_string)s;
> >       def visit_command(self, name, info, ifcond, arg_type, ret_type, gen,
> >                         success_response, boxed, allow_oob, allow_preconfig,
> > -                      features):
> > +                      coroutine, features):
> >           arg_type = arg_type or self._schema.the_empty_object_type
> >           ret_type = ret_type or self._schema.the_empty_object_type
> >           obj = {'arg-type': self._use_type(arg_type),
> 
> I'm assuming the new flag is internal only, and doesn't affect behavior seen
> by the user, and thus nothing to change in the introspection output.

Yes. The result would hopefully be visible to the user (the guest
doesn't hang any more where it used to hang), but that's just a bug fix
and nothing that would require a change in the way a client uses QMP.

Kevin



  reply	other threads:[~2020-01-13 10:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 18:35 [PATCH 0/4] qmp: Optionally run handlers in coroutines Kevin Wolf
2020-01-09 18:35 ` [PATCH 1/4] qapi: Add a 'coroutine' flag for commands Kevin Wolf
2020-01-10 19:00   ` Eric Blake
2020-01-13 10:46     ` Kevin Wolf [this message]
2020-01-09 18:35 ` [PATCH 2/4] block: Mark 'block_resize' as coroutine Kevin Wolf
2020-01-13 16:56   ` Stefan Hajnoczi
2020-01-13 17:10     ` Kevin Wolf
2020-01-14 16:30       ` Stefan Hajnoczi
2020-01-09 18:35 ` [PATCH 3/4] vl: Initialise main loop earlier Kevin Wolf
2020-01-09 18:35 ` [PATCH 4/4] qmp: Move dispatcher to a coroutine Kevin Wolf
2020-01-13  7:00 ` [PATCH 0/4] qmp: Optionally run handlers in coroutines Marc-André Lureau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200113104644.GD5549@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).