Re: [Qemu-devel] [RFC v5 07/26] monitor: unify global init

[Peter Xu]

On Mon, Dec 18, 2017 at 09:24:57AM +0000, Stefan Hajnoczi wrote:
> On Mon, Dec 18, 2017 at 11:27:02AM +0800, Peter Xu wrote:
> > On Sat, Dec 16, 2017 at 09:01:12AM +0000, Stefan Hajnoczi wrote:
> > > On Sat, Dec 16, 2017 at 11:52:28AM +0800, Peter Xu wrote:
> > > > On Fri, Dec 15, 2017 at 12:47:11PM +0000, Stefan Hajnoczi wrote:
> > > > > On Fri, Dec 15, 2017 at 04:11:41PM +0800, Peter Xu wrote:
> > > > > > On Wed, Dec 13, 2017 at 03:48:06PM +0000, Stefan Hajnoczi wrote:
> > > > > > > On Tue, Dec 05, 2017 at 01:51:41PM +0800, Peter Xu wrote:
> > >  }
> > > 
> > > Now vl.c:main() doesn't need to initialize the monitor.
> > > 
> > > We still need to handle the qtest_enabled() dependency:
> > > 
> > > -static QEMUClockType event_clock_type = QEMU_CLOCK_REALTIME;
> > > +static inline QEMUClockType event_clock_type(void)
> > > +{
> > > +    return qtest_enabled() ? QEMU_CLOCK_VIRTUAL : QEMU_CLOCK_REALTIME;
> > > +}
> > > 
> > > This way the qtest_enabled() call is deferred until later when the
> > > accelerators have been initialized.
> > 
> > Or... to be much simpler... How about we just use my patch?  IMHO it
> > calls monitor_init_globals() after configure_accelerator() so
> > monitor_qapi_event_init() and everything else would just work as
> > expected?
> 
> Ordering is complex in vl.c:main() so I think it's more maintainable to
> put initialization in a monitor.c constructor function and/or
> monitor_init().
> 
> If you want to keep your approach please add a comment about the
> qtest_enabled() dependency in vl.c:main().

Actually I still think this patch is the cleanest solution considering
all the above limitations. So I'll keep this one.  But for sure I can
add a comment mentioning about the dependency to accelerator codes.

Thanks!

-- 
Peter Xu