On 05/14/2014 09:20 PM, Jeff Cody wrote: > Currently, node_name is only filled in when done so explicitly by the > user. If no node_name is specified, then the node name field is not > populated. > > If node_names are automatically generated when not specified, that means > that all block job operations can be done by reference to the unique > node_name field. This eliminates ambiguity in filename pathing > (relative filenames, or file descriptors, symlinks, mounts, etc..) that > qemu currently needs to deal with. > > If a node name is specified, then it will not be automatically > generated for that BDS entry. > > If it is automatically generated, it will be prefaced with "__qemu##", > followed by 8 characters of a unique number, followed by 8 random > ASCII characters in the range of 'A-Z'. Some sample generated node-name > strings: > __qemu##00000000IAIYNXXR > __qemu##00000002METXTRBQ > __qemu##00000001FMBORDWG > > 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 <jc...@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. 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? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
