On 03/12/2014 04:13 AM, Markus Armbruster wrote:
> Cole Robinson <crobi...@redhat.com> writes:
>
>> These errors don't seem user initiated, so forcibly printing to the
>> monitor doesn't seem right. Just print to stderr.
>>
>> Drop lprint since it's now unused.
>>
>> Cc: Jan Kiszka <jan.kis...@siemens.com>
>> Signed-off-by: Cole Robinson <crobi...@redhat.com>
>> ---
>> checkpatch flags some pre-existing tab issues, but I didn't retab. Should I?
>>
>> slirp/misc.c | 13 ++-----------
>> slirp/slirp.c | 8 ++++----
>> slirp/slirp.h | 2 --
>> 3 files changed, 6 insertions(+), 17 deletions(-)
>>
>> diff --git a/slirp/misc.c b/slirp/misc.c
>> index 6c1636f..662fb1d 100644
>> --- a/slirp/misc.c
>> +++ b/slirp/misc.c
>> @@ -136,7 +136,7 @@ fork_exec(struct socket *so, const char *ex, int do_pty)
>> if ((s = qemu_socket(AF_INET, SOCK_STREAM, 0)) < 0 ||
>> bind(s, (struct sockaddr *)&addr, addrlen) < 0 ||
>> listen(s, 1) < 0) {
>> - lprint("Error: inet socket: %s\n", strerror(errno));
>> + fprintf(stderr, "Error: inet socket: %s\n",
>> strerror(errno));
>> closesocket(s);
>>
>> return 0;
>
> Why not error_report()?
>
> [...]
>
AFAICT this is only guest initiated, never from the monitor. error_report
sends output to cur_mon if a monitor command is being processed. If this
message triggers while a different monitor command is being processed, do we
really want this unrelated output to go to the monitor?
(Maybe that can't happen in practice, I don't know enough about qemu's
threading model, but I was being cautious)
- Cole
