qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: fromani@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator
Date: Tue, 9 Sep 2014 15:23:50 +0200	[thread overview]
Message-ID: <20140909132350.GJ4847@noname.str.redhat.com> (raw)
In-Reply-To: <540EF82E.60602@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]

Am 09.09.2014 um 14:53 hat Eric Blake geschrieben:
> On 09/09/2014 06:43 AM, Luiz Capitulino wrote:
> 
> >> Enhancing query-block in addition to the event makes sense, if it is
> >> easy enough to do.  At this point, we are talking about debugging aids,
> >> so as long as they are documented appropriately, I won't be too fussy.
> > 
> > OK, but I'm wondering if we need to add the string field to both,
> > BLOCK_IO_ERROR and query-block, or only to one to the other.
> > 
> > In my opinion, we should only add it to BLOCK_IO_ERROR if libvirt is
> > going to consume. Otherwise, it makes more sense to add it to query-block
> > because that's where we'll meet the user.
> > 
> > Btw, by "consume" I mean read it and make it available to libvirt clients
> > so that they can print it to their users. If we don't want libvirt to
> > consume that field then I think we should only add it to query-block and
> > info block.
> 
> [For those not aware, qemu built for downstream RHEL already has an
> error string in the __com.redhat_ namespace; we're trying to figure out
> what upstream should have so that downstream doesn't have to perpetually
> maintain an extension]
> 
> Downstream libvirt does not currently consume any error string.  With
> downstream qemu, the _only_ way to get the error string in the event is
> to parse libvirt logs, or use upstream libvirt with its backdoor of
> 'virsh qemu-monitor-event' (through the explicitly unsupported
> libvirt-qemu.so) to get at the raw event information.  Changing libvirt
> to expose such an error string to the end user would require a new
> libvirt event number (the existing libvirt event is not extensible), so
> existing clients would not be able to get at the information without
> being recompiled to a new libvirt.
> 
> Since the whole point of this field is for debugging, I think that it is
> sufficient to add it to JUST query-block, and not to the event.  That
> is, if the app on top of libvirt gets an error, in the common case, they
> won't care about the message (it won't change how they act), and in the
> debug case, a developer trying to learn more about what happened can do
> their own query-block directly (via 'virsh qemu-monitor-command', also
> in libvirt-qemu.so) rather than trying to wire up libvirt to pass
> through an error string through a new event.

You mention libvirt logs and I think that's an important point: If we
move it to query-block, will we still get a log entry so that we can
check this after the fact when only a log file is attached to a bug
report, but we don't have a running guest?

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-09-09 13:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 20:07 [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator Luiz Capitulino
2014-08-29 20:33 ` Eric Blake
2014-09-08 14:42 ` Luiz Capitulino
2014-09-08 15:33   ` Kevin Wolf
2014-09-08 16:57     ` Luiz Capitulino
2014-09-09  8:27       ` Kevin Wolf
2014-09-09 12:37         ` Eric Blake
2014-09-09 12:43           ` Luiz Capitulino
2014-09-09 12:53             ` Eric Blake
2014-09-09 13:23               ` Kevin Wolf [this message]
2014-09-09 13:42                 ` Luiz Capitulino

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=20140909132350.GJ4847@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=fromani@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).