* Peter Maydell (peter.mayd...@linaro.org) wrote: > 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.
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 / dgilb...@redhat.com / Manchester, UK
