"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
> * Markus Armbruster (arm...@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?
