On 19 October 2015 at 15:29, Markus Armbruster <arm...@redhat.com> 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