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

[Peter Maydell]

On 19 October 2015 at 15:29, Markus Armbruster <address@hidden> wrote:
> Points I'd like to make:
>
> 1. Logging is not tracing.  Logging logs events interesting for the
> user.  Tracing logs code execution.  It's a debugging aid.  The two
> overlap to a degree, but they're not the same.

In the case of QEMU, the event the user is often interested in
is (guest) code execution...

> 2. The current use of log.h seems closer to tracing than to logging.

Maybe. It gets a fair amount of use for "figure out what my
guest is doing" questions.

> 3. I figure our tracing needs could be served by the tracing subsystem
> with a few improvements.  The few things log.h can do that tracing can't
> yet do should be easy enough to add.  Why have two separate subsystems
> then?

I just feel that the logging subsystem is very simple and easy
to use. The tracing subsystem is far from easy to comprehend.
I'm apprehensive that in the name of simplification we'll end up
deleting the easy to use logging without making the tracing
as easy for end users to use.

> 4. Logging would be useful, but I feel it shouldn't be shoehorned into
> log.h.

The log.h code is definitely intended for our end users to run.
It's true that at the moment we log the things that are easy
to log rather than having the flexibility to log the things
end users would ideally like; but the solution to that is to
improve the logging...

In particular, ideally the logging should allow you to debug or
instrument your guest program without having to care about QEMU's
internals particularly. LOG_UNIMP and LOG_GUEST_ERROR are moving
in that direction.

thanks
-- PMM