qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] Fix socket chardev regression


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH 0/4] Fix socket chardev regression
Date: Wed, 22 Aug 2018 14:55:43 +0800
User-agent: Mutt/1.10.1 (2018-07-13)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]