[libvirt] [PATCH] storage: pick return value of qemu-img
Eric Blake
eblake at redhat.com
Mon May 23 19:06:59 UTC 2011
On 05/23/2011 05:45 AM, Daniel P. Berrange wrote:
> On Mon, May 23, 2011 at 09:19:21AM +0200, Michal Privoznik wrote:
>> qemu-img returns non-zero status on -h. Therefore we need to
>> provide virCommandRun() a non-NULL exit status pointer.
>> ---
>> src/storage/storage_backend.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
>> index f90425a..c8e19c8 100644
>> --- a/src/storage/storage_backend.c
>> +++ b/src/storage/storage_backend.c
>> @@ -621,13 +621,14 @@ static int virStorageBackendQEMUImgBackingFormat(const char *qemuimg)
>> char *end;
>> char *tmp;
>> int ret = -1;
>> + int exitstatus;
>> virCommandPtr cmd = virCommandNewArgList(qemuimg, "-h", NULL);
>>
>> virCommandAddEnvString(cmd, "LC_ALL=C");
>> virCommandSetOutputBuffer(cmd, &help);
>> virCommandClearCaps(cmd);
>>
>> - if (virCommandRun(cmd, NULL) < 0)
>> + if (virCommandRun(cmd, &exitstatus) < 0)
A comment would have been helpful here (see a similar comment in
qemu/qemu_capabilies.c ignoring failure from old qemu that does not
understand -M), if only to document why we passed &exitstatus instead of
NULL, even though we don't parse exitstatus.
Hmm, I'm also wondering if virCommandRun should return -1 unless
exitstatus corresponds to WIFEXITED (that is, if the child died from a
signal, should the caller be burdened with checking that, or should
exitstatus be guaranteed to be a normal exit status with signal exits
still filtered out by virCommand).
--
Eric Blake eblake at redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110523/50bd563c/attachment-0001.sig>
More information about the libvir-list
mailing list