All of lore.kernel.org
 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 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.