[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 09/17] target: Simplify how the TARGET_cpu_list(
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH 09/17] target: Simplify how the TARGET_cpu_list() print |
Date: |
Tue, 16 Apr 2019 09:20:45 +0100 |
User-agent: |
Mutt/1.11.4 (2019-03-13) |
* Markus Armbruster (address@hidden) wrote:
> "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?
Yes, thanks!
Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK