On 04/23/2010 11:00 AM, Dave Allan wrote:
On Fri, Apr 23, 2010 at 03:52:41PM +0100, Daniel P. Berrange wrote:
On Fri, Apr 23, 2010 at 08:41:54AM -0600, Eric Blake wrote:
On 04/22/2010 12:32 PM, David Allan wrote:
* Fix for the bug reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=573908
---
src/conf/storage_encryption_conf.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/conf/storage_encryption_conf.c b/src/conf/storage_encryption_conf.c
index ed71688..7f68d67 100644
--- a/src/conf/storage_encryption_conf.c
+++ b/src/conf/storage_encryption_conf.c
@@ -228,7 +228,7 @@ virStorageEncryptionSecretFormat(virBufferPtr buf,
}
virUUIDFormat(secret->uuid, uuidstr);
- virBufferVSprintf(buf, "<secret type='%s' uuid='%s'/>\n", type, uuidstr);
+ virBufferVSprintf(buf, "<secret type='%s' uuid='%s'/>\n", type, uuidstr);
This patch breaks tests/storagevolxml2xmltest, which needs a
corresponding change to the expected alignment.
Actually I think the problem here is that the encryption XML is used from
two different places - the domain XML and the storage volume XML. The usage
in each of these two XML docs needs a different indentation. There is no
one-size-fits-all solution. We should make the caller pass in a suitable
const char *indent = " "; string to match their use context.
Ugh, sorry about that. The const char *indent approach seems like the
right one to me. I'll fix that right now.
I haven't looked at the code throughtly, but if there's a possibility
that the caller is already indented, so doesn't know just how much
indentation to send to the subordinate function (or that it might happen
in the future), you could pass around an "int indent" instead of a
char*, and reference it in the printf like this:
virBufferVSprintf(buf, "%*s<secret type='%s' uuid='%s'/>\n",
indent*2, type, uuidstr);
similar to what I did in interface_conf.c:virInterfaceDefDevFormat() (I
called it "level", but same idea). (Of course, I needed something that
could be called recursively, while your usage probably doesn't need that.)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list