Re: [Qemu-trivial] [Qemu-devel] [PATCH] ide: log error when trying to use ATAPI overlapping features

[Peter Maydell]

On 11 February 2013 14:19, Andreas Färber <address@hidden> wrote:
> Am 11.02.2013 15:01, schrieb Markus Armbruster:
>> Kevin Wolf <address@hidden> writes:
>>
>>> Am 11.02.2013 14:27, schrieb Stefan Hajnoczi:
>>>> I think we need to side-track this patch email to figure out what to
>>>> use:
>>>>
>>>> fprintf(stderr) - some warnings/errors use this
>>>> error_report() - goes to the monitor, if possible, otherwise stderr
>>>
>>> These look wrong to me.
>>
>> "Wrong" is a bit strong, in particular since there's ample precedence
>> for these uses.

Certainly for fprintf() I would say "deprecated" wherever
we have a better API available.

>>>> qemu_log_*() - goes to the qemu log, seems a little TCG-centric
>>>
>>> I would suggest either this or just trace points. (And by the way, it's
>>> a pity that -d is so TCG-centric, it's been more than once the reason
>>> why I disabled KVM when debugging a guest... Having at least -d int
>>> would be so useful.)
>>
>> Tracepoints don't really fit when we want to report the guest does
>> something we don't handle.  Users deserve fair warning then, don't they?
>>
>> Could qemu_log() & friends be made fit for general use?  What's missing?
>
> Blue already did some work to make it more usable, and I believe Peter
> adopted LOG_UNIMPL for ARM devices in place of hw_error()

Yes; in particular where we have classes of error message which the
user may wish to enable or disable (of which "QEMU doesn't implement
this" and "the guest just did something that's probably a guest bug"
are two common ones) qemu_log_mask(LOG_*, ...) is the preferred
API for devices IMHO. So I think Herve's patch is entirely the
right thing.

Tracepoints are IMHO pretty useless for this kind of message
because they're a compile time setup, not runtime, and they don't
have useful message categories. We should be expanding the use
of the qemu_log() API. If we need more categories and/or more
flexibility about where the logging goes [eg an option to direct
the logs to monitor?] we can add them.

-- PMM