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