Re: [Qemu-devel] What's the intended use of log.h logging?

[Paolo Bonzini]

On 16/10/2015 14:54, Peter Maydell wrote:
> On 16 October 2015 at 13:48, Paolo Bonzini <address@hidden> wrote:
>>
>>
>> On 16/10/2015 14:33, Markus Armbruster wrote:
>>>    Looks like this is basically TCG with a couple of random LOG_UNIMP
>>>    and LOG_GUEST_ERROR thrown in.  It's definitely not a general purpose
>>>    QEMU log in its current state.
>>
>> I think these could become error_report.
> 
> No; it's important not to print these unless the user really
> asked for them (especially the GUEST_ERROR) kind. Otherwise it's
> (potentially quite a lot of) unnecessary noise.

I guess it depends then.  If the unimplemented feature is in all
likelihood a showstopper (e.g. setend) it should be unconditionally
enabled, I think.

>> Some others (e.g. LOG_IOPORT) can be removed.
>>
>> LOG_MMU seems to be mostly a ppc thing, could also become a tracepoint.
>>  Likewise for LOG_PCALL and perhaps LOG_INT.
> 
> It's also very useful to be able to enable whole *classes* of
> tracing (like "tell me whenever my guest OS does something dumb");
> does the tracepoint code have any support for this?

That's part of what I mentioned in my message ("add some functionality
to enable tracepoints more easily").  It would be great to have
something like "-d trace:scsi_*" on the command line, integrated with
qemu-log.

So perhaps the place of qemu-log is as a replacement for the stderr
tracing backend?

Paolo