From: Peter Xu <peterx@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
QEMU <qemu-devel@nongnu.org>,
"Daniel P. Berrange" <berrange@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] Fix socket chardev regression
Date: Wed, 22 Aug 2018 14:55:43 +0800 [thread overview]
Message-ID: <20180822065543.GH3324@xz-x1> (raw)
In-Reply-To: <20180822034632.GB3324@xz-x1>
On Wed, Aug 22, 2018 at 11:46:32AM +0800, Peter Xu wrote:
> On Tue, Aug 21, 2018 at 04:16:27PM +0200, Paolo Bonzini wrote:
> > On 21/08/2018 16:04, Marc-André Lureau wrote:
> > >> If you don't like the way I proposed, another thing I am
> > >> thinking is that whether we can assign the gcontext for the chardev
> > >> backend before initialization of it (or by parsing the backend &
> > >> frontend relationships before init of backends), then we assure that
> > >> we never change the gcontext of any chardev backends. Though that
> > > Yes, I think that's a cleaner solution. I suggested to use an iothread
> > > argument in the cover letter.
> >
> > That would be nice, but isn't it already too late for the monitor chardev?
>
> I think, yes, if we want to do this automatically.
Sorry I forgot to mention some more details here. If to do it
automatically, IMHO we can just split the mon_init_func() into parsing
and init, then we do:
(1) parse monitors, setup gcontext/... for chardev
(2) init chardevs with the gcontext/... setup
(3) init monitors
Benefit is that we don't need to introduce new interface then.
> Though if as
> Marc-André suggested (which I didn't really notice first when reading
> the cover letter), then maybe that's not a problem since user need to
> manually specify the iothread for a chardev backend, then chardev
> context will not depend on monitor code any more.
>
> Marc-André, do you want to propose your iothread interface? That
> should be the easy way AFAIU, though that'll make the command line for
> monitor out-of-band much longer (but it seems fine at least to me).
>
> Adding Markus too.
>
> >
> > In any case, I don't see a reason to dislike this patch, especially
> > since it comes with a testcase.
>
> AFAIU the test case didn't really test the non-NULL gcontext case, so
> it fixed A (vhost-user reconnect) however it might break B (non-NULL
> gcontext with a potential race).
>
> Regards,
>
> --
> Peter Xu
Regards,
--
Peter Xu
prev parent reply other threads:[~2018-08-22 6:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 13:52 [Qemu-devel] [PATCH 0/4] Fix socket chardev regression Marc-André Lureau
2018-08-17 13:52 ` [Qemu-devel] [PATCH 1/4] Revert "chardev: tcp: postpone TLS work until machine done" Marc-André Lureau
2018-08-17 13:52 ` [Qemu-devel] [PATCH 2/4] Revert "chardev: tcp: postpone async connection setup" Marc-André Lureau
2018-08-17 13:52 ` [Qemu-devel] [PATCH 3/4] char-socket: update all ioc handlers when changing context Marc-André Lureau
2018-08-17 13:52 ` [Qemu-devel] [PATCH 4/4] test-char: add socket reconnect test Marc-André Lureau
2018-08-20 2:45 ` [Qemu-devel] [PATCH 0/4] Fix socket chardev regression Peter Xu
2018-08-20 15:37 ` Marc-André Lureau
2018-08-21 6:29 ` Peter Xu
2018-08-21 14:04 ` Marc-André Lureau
2018-08-21 14:14 ` Daniel P. Berrangé
2018-08-21 14:16 ` Paolo Bonzini
2018-08-22 3:46 ` Peter Xu
2018-08-22 6:55 ` Peter Xu [this message]
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=20180822065543.GH3324@xz-x1 \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=pbonzini@redhat.com \
--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.