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

[Markus Armbruster]

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Markus Armbruster (address@hidden) 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?