All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Eduardo Habkost <eduardo@habkost.net>,
	Peter Maydell <peter.maydell@linaro.org>,
	Beraldo Leal <bleal@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Hanna Reitz <hreitz@redhat.com>, Cleber Rosa <crosa@redhat.com>
Subject: Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
Date: Fri, 4 Feb 2022 16:23:17 -0500	[thread overview]
Message-ID: <CAFn=p-axYaoe6KFmqXVG+ieNv93zg_XhHzd5-JJe7oP2v4wiWw@mail.gmail.com> (raw)
In-Reply-To: <YfueFuHpHx6TXCMR@redhat.com>

On Thu, Feb 3, 2022 at 4:19 AM Kevin Wolf <kwolf@redhat.com> wrote:
>
> Am 02.02.2022 um 20:08 hat John Snow geschrieben:
> > > I guess the relevant question in the context of this patch is whether
> > > sync.py will need a similar two-phase setup as legacy.py. Do you think
> > > you can do without it when you have to reintroduce this behaviour here
> > > to fix bugs?
> > >
> >
> > Hm, honestly, no. I think you'll still need the two-phase in the sync
> > version no matter what -- if you expect to be able to launch QMP and
> > QEMU from the same process, anyway. I suppose it's just a matter of
> > what you *call* it and what/where the arguments are.
> >
> > I could just call it bind(), and it does whatever it needs to (Either
> > creating a socket or, in 3.7+, instantiating more of the asyncio loop
> > machinery).
> > The signature for accept() would need to change to (perhaps)
> > optionally accepting no arguments; i.e. you can do either of the
> > following:
> >
> > (1) qmp.bind('/tmp/sock')
> >     qmp.accept()
> >
> > (2) qmp.accept('/tmp/sock')
> >
> > The risk is that the interface is just a touch more complex, the docs
> > get a bit more cluttered, there's a slight loss of clarity, the
> > accept() method would need to check to make sure you didn't give it an
> > address argument if you've already given it one, etc. Necessary
> > trade-off for the flexibility, though.
>
> Hm, how about copying the create_server() interface instead? So it
> would become:
>
> (1) qmp.create_server('/tmp/sock', start_serving=False)
>     qmp.start_serving()
>
> (2) qmp.create_server('/tmp/sock')
>
> Then you get the connection details only in a single place. (The names
> should probably be changed because we're still a QMP client even though
> we're technically the server on the socket level, but you get the idea.)

Good idea. I'll experiment.

(I'm worried that the way I initially factored the code to begin with
might make this ugly, but maybe I'm just dreading nothing. I'll have
to see.)

Thanks for taking a look!

--js



  reply	other threads:[~2022-02-04 21:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01  4:11 [PATCH v4 0/4] Python: Improvements for iotest 040,041 John Snow
2022-02-01  4:11 ` [PATCH v4 1/4] python/aqmp: Fix negotiation with pre-"oob" QEMU John Snow
2022-02-01 12:59   ` Kevin Wolf
2022-02-01 18:33     ` John Snow
2022-02-01  4:11 ` [PATCH v4 2/4] python/machine: raise VMLaunchFailure exception from launch() John Snow
2022-02-01  4:11 ` [PATCH v4 3/4] python: upgrade mypy to 0.780 John Snow
2022-02-01  4:11 ` [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py John Snow
2022-02-01 13:21   ` Kevin Wolf
2022-02-01 18:32     ` John Snow
2022-02-01 19:46       ` Kevin Wolf
2022-02-02 19:08         ` John Snow
2022-02-03  9:19           ` Kevin Wolf
2022-02-04 21:23             ` John Snow [this message]
2022-02-03  9:38           ` Daniel P. Berrangé
2022-02-04  0:25             ` John Snow
2022-02-01 13:28 ` [PATCH v4 0/4] Python: Improvements for iotest 040,041 Kevin Wolf
2022-02-01 18:16   ` John Snow

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='CAFn=p-axYaoe6KFmqXVG+ieNv93zg_XhHzd5-JJe7oP2v4wiWw@mail.gmail.com' \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.