From: Eric Blake <eblake@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
fromani@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block: extend BLOCK_IO_ERROR event with nospace indicator
Date: Tue, 09 Sep 2014 06:53:02 -0600 [thread overview]
Message-ID: <540EF82E.60602@redhat.com> (raw)
In-Reply-To: <20140909084353.454cc889@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]
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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]
next prev parent reply other threads:[~2014-09-09 12:53 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 [this message]
2014-09-09 13:23 ` Kevin Wolf
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=540EF82E.60602@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=fromani@redhat.com \
--cc=kwolf@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).