Re: [Qemu-devel] [PATCH 09/17] target: Simplify how the TARGET_cpu_list() print

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Markus Armbruster (armbru@redhat.com) wrote:
> >> The various TARGET_cpu_list() take an fprintf()-like callback and a
> >> FILE * to pass to it.  Their callers (vl.c's main() via list_cpus(),
> >> bsd-user/main.c's main(), linux-user/main.c's main()) all pass
> >> fprintf() and stdout.  Thus, the flexibility provided by the (rather
> >> tiresome) indirection isn't actually used.
> >> 
> >> Drop the callback, and call qemu_fprintf() instead.
> >
> > Actually calling qemu_printf
> 
> Typo, will fix.  Thanks!
> 
> >> Calling printf() would also work, but would make the code unsuitable
> >> for monitor context without making it simpler.
> >
> > Gernally OK; but just checking - are there any flag combos that will
> > mean this ends up with the result going down a monitor rather than
> > stdout, and will that upset something like libvirt that might be using
> > this to enumerate a cpu list?
> 
> No.
> 
> qemu_printf() prints to current monitor if we have one, else to stdout.
> Thus, it prints to stdout as long as !cur_mon.
> 
> cur_mon is thread-local, and always set like this:
> 
>     Monitor *old_mon = cur_mon;
>     cur_mon = ... non-null value ...
>     ... do something ...
>     cur-mon = old_mon;
> 
> It's set and restored
> 
> * in monitor_qmp_dispatch() around executing a QMP command
> 
> * in monitor_read() around handling HMP input (this includes executing
>   a command)
> 
> * in qmp_human_monitor_command() around executing the HMP command (this
>   is where monitors become nested)
> 
> Therefore, cur_mon is null unless we're executing a QMP command, an HMP
> command, or are processing HMP input.
> 
> Clearer now?

Yes, thanks!

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK