All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Pavel Butsykin <pbutsykin@virtuozzo.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Denis V. Lunev" <den@openvz.org>,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] What's the intended use of log.h logging?
Date: Mon, 19 Oct 2015 17:57:12 +0100	[thread overview]
Message-ID: <20151019165712.GD2462@work-vm> (raw)
In-Reply-To: <CAFEAcA9hWTmFBJVs_cu1LpmCYrfas1FqtW5ziG9BJfCZOL2uBw@mail.gmail.com>

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 19 October 2015 at 15:29, Markus Armbruster <armbru@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 / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2015-10-19 16:57 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15  7:30 [Qemu-devel] [PATCH 0/3] QEMU logging improvements Denis V. Lunev
2015-10-15  7:30 ` [Qemu-devel] [PATCH 1/3] log: improve performance of qemu_log and qemu_log_mask if disabled Denis V. Lunev
2015-10-15 17:23   ` Alex Bennée
2015-10-15 17:40     ` Denis V. Lunev
2015-10-15 18:36       ` Alex Bennée
2015-10-16  7:17   ` Markus Armbruster
2015-10-16  7:45     ` Denis V. Lunev
2015-10-16 11:02       ` Markus Armbruster
2015-10-16 11:08         ` Denis V. Lunev
2015-10-15  7:30 ` [Qemu-devel] [PATCH 2/3] log: report hmp/qmp command and qmp event Denis V. Lunev
2015-10-16  7:34   ` Markus Armbruster
2015-10-16  9:51     ` Pavel Butsykin
2015-10-16 12:35       ` Markus Armbruster
2015-10-16 12:33   ` [Qemu-devel] What's the intended use of log.h logging? (was: [PATCH 2/3] log: report hmp/qmp command and qmp event) Markus Armbruster
2015-10-16 12:48     ` [Qemu-devel] What's the intended use of log.h logging? Paolo Bonzini
2015-10-16 12:54       ` Peter Maydell
2015-10-16 13:00         ` Paolo Bonzini
2015-10-16 13:38           ` Denis V. Lunev
2015-10-16 13:26         ` Daniel P. Berrange
2015-10-16 13:29           ` Peter Maydell
2015-10-16 13:30             ` Paolo Bonzini
2015-10-16 13:36               ` Peter Maydell
2015-10-16 14:17                 ` Paolo Bonzini
2015-10-16 14:31                   ` Peter Maydell
2015-10-16 15:27                     ` Paolo Bonzini
2015-10-19 13:17                     ` Markus Armbruster
2015-10-19 13:19                       ` Paolo Bonzini
2015-10-19 13:54                       ` Peter Maydell
2015-10-16 12:51     ` [Qemu-devel] What's the intended use of log.h logging? (was: [PATCH 2/3] log: report hmp/qmp command and qmp event) Peter Maydell
2015-10-19 14:29       ` [Qemu-devel] What's the intended use of log.h logging? Markus Armbruster
2015-10-19 14:41         ` Peter Maydell
2015-10-19 16:57           ` Dr. David Alan Gilbert [this message]
2015-10-19 17:02         ` Dr. David Alan Gilbert
2015-10-20 13:11         ` Kevin Wolf
2015-10-16 14:36     ` [Qemu-devel] What's the intended use of log.h logging? (was: [PATCH 2/3] log: report hmp/qmp command and qmp event) Alex Bennée
2015-10-19 14:52       ` [Qemu-devel] What's the intended use of log.h logging? Markus Armbruster
2015-10-19 14:57         ` Peter Maydell
2015-10-21 10:41     ` [Qemu-devel] What's the intended use of log.h logging? (was: [PATCH 2/3] log: report hmp/qmp command and qmp event) Stefan Hajnoczi
2015-10-21 11:10       ` [Qemu-devel] What's the intended use of log.h logging? Denis V. Lunev
2015-10-21 12:22       ` [Qemu-devel] What's the intended use of log.h logging? (was: [PATCH 2/3] log: report hmp/qmp command and qmp event) Peter Maydell
2015-10-22 12:26         ` Stefan Hajnoczi
2015-10-22 13:05           ` [Qemu-devel] What's the intended use of log.h logging? Paolo Bonzini
2015-10-15  7:30 ` [Qemu-devel] [PATCH 3/3] log: adds a timestamp to each log entry Denis V. Lunev
2015-10-16  7:49   ` Markus Armbruster
2015-10-16  9:55     ` Pavel Butsykin
2015-10-16 11:33       ` Markus Armbruster
2015-10-15 14:49 ` [Qemu-devel] [PATCH 0/3] QEMU logging improvements Kashyap Chamarthy
2015-10-15 15:18   ` Pavel Butsykin
2015-10-15 16:02     ` Kashyap Chamarthy
2015-10-26  9:16 ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151019165712.GD2462@work-vm \
    --to=dgilbert@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=lcapitulino@redhat.com \
    --cc=pbutsykin@virtuozzo.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.