From: Eric Blake <eblake@redhat.com>
To: Jeff Cody <jcody@redhat.com>
Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com,
famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/5] block: Auto-generate node_names for each BDS entry
Date: Thu, 15 May 2014 13:12:07 -0600 [thread overview]
Message-ID: <53751187.5050608@redhat.com> (raw)
In-Reply-To: <20140515184103.GM8452@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]
On 05/15/2014 12:41 PM, Jeff Cody wrote:
>>> The prefix is to aid in identifying it as a qemu-generated name, the
>>> numeric portion is to guarantee uniqueness in a given qemu session, and
>>> the random characters are to further avoid any accidental collisions
>>> with user-specified node-names.
>>>
>>> Signed-off-by: Jeff Cody <jcody@redhat.com>
>>> ---
>>> block.c | 16 +++++++++++++++-
>>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> This patch feels incomplete. We probably also ought to modify
>> qapi-schema.json to make BlockDeviceInfo's output of 'node-name' by
>> unconditional (as an output-only struct, changing from optional to
>> mandatory is a safe change for back-compat API considerations); which
>> implies further modifying code to get rid of has_node_name arguments in
>> all places that generate BlockDeviceInfo details.
>
> I think it should be a separate patch (but still in this series).
> Strictly speaking, this patch doesn't force the argument to be
> mandatory, the value just happens to always be populated now.
True, keeping it as two patches is cleaner.
>
>> See also my thoughts on patch 5/5 - can this patch be rebased to be LAST
>> in the series, rather than first, so that it serves as a reliable
>> witness that everything else related to block operations on node-names
>> is complete?
>>
> How about this becomes the penultimate patch, and the patch to make
> BlockDeviceInfo's node-name field to be unconditional becomes the last
> patch?
Or, if we go the route of adding a new command for setting the backing
name in isolation, then _that_ patch should be last, at which point
leaving this patch early in the series no longer hurts, because it is no
longer the witness that libvirt would be relying on.
>
> The only thing I don't like about moving this further back in the
> patch series is it makes the earlier patches untestable; I can't
> easily test the usage of the node-names for various intermediate BDS
> because they don't have node-names set. So that means I'll just need
> to rebase the patches prior to sending. So let me revise my above
> statement - how about this patch stays at the beginning, which makes
> development / testing easier, with the patch that modifies
> BlockDeviceInfo as the final (not including tests) patch?
Yes, keeping this patch first sounds reasonable after all. The patch
modifying BlockDeviceInfo isn't introspectible (there's nothing libvirt
can probe that says whether the QMP code switched from optional to
mandatory - all libvirt can probe is whether a name gets generated - and
that is THIS patch, not the BlockDeviceInfo patch). But adding a new
command is easier to use than probing whether a name was generated.
>
>
--
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: 604 bytes --]
next prev parent reply other threads:[~2014-05-15 19:12 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 3:20 [Qemu-devel] [PATCH 0/5] block: Modify block-commit to use node-names Jeff Cody
2014-05-15 3:20 ` [Qemu-devel] [PATCH 1/5] block: Auto-generate node_names for each BDS entry Jeff Cody
2014-05-15 11:58 ` Benoît Canet
2014-05-15 12:06 ` Jeff Cody
2014-05-15 12:32 ` Benoît Canet
2014-05-15 12:37 ` Jeff Cody
2014-05-15 14:11 ` Eric Blake
2014-05-15 15:59 ` Eric Blake
2014-05-15 18:41 ` Jeff Cody
2014-05-15 19:12 ` Eric Blake [this message]
2014-05-16 9:39 ` Kevin Wolf
2014-05-16 11:35 ` Jeff Cody
2014-05-16 12:47 ` Eric Blake
2014-05-16 17:16 ` Kevin Wolf
2014-05-15 3:20 ` [Qemu-devel] [PATCH 2/5] block: add helper function to determine if a BDS is in a chain Jeff Cody
2014-05-15 11:48 ` Benoît Canet
2014-05-15 14:16 ` Eric Blake
2014-05-15 14:24 ` Kevin Wolf
2014-05-15 14:31 ` Jeff Cody
2014-05-15 3:20 ` [Qemu-devel] [PATCH 3/5] block: make 'top' argument to block-commit optional Jeff Cody
2014-05-15 11:47 ` Benoît Canet
2014-05-15 11:49 ` Jeff Cody
2014-05-15 15:07 ` Eric Blake
2014-05-15 3:20 ` [Qemu-devel] [PATCH 4/5] block: Accept node-name arguments for block-commit Jeff Cody
2014-05-15 12:09 ` Benoît Canet
2014-05-15 15:42 ` Eric Blake
2014-05-15 18:04 ` Jeff Cody
2014-05-15 3:20 ` [Qemu-devel] [PATCH 5/5] block: extend block-commit to accept a string for the backing file Jeff Cody
2014-05-15 12:26 ` Benoît Canet
2014-05-15 12:57 ` Eric Blake
2014-05-15 13:10 ` Jeff Cody
2014-05-15 13:14 ` Eric Blake
2014-05-15 16:06 ` Eric Blake
2014-05-15 18:22 ` Jeff Cody
2014-05-15 18:52 ` Eric Blake
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=53751187.5050608@redhat.com \
--to=eblake@redhat.com \
--cc=benoit.canet@irqsave.net \
--cc=famz@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=pkrempa@redhat.com \
--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 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).