qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC v5 07/26] monitor: unify global init
Date: Mon, 18 Dec 2017 09:24:57 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

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().

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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