[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