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

[Dr. David Alan Gilbert]

* Peter Maydell (address@hidden) wrote:
> 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.

When I first looked at it, I thought the same way, but then
I found the stderr mode, and it's really very easy.

Dave

> > 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
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK