[libvirt] [PATCH 4/4] storage: Always report an error from VolOpen

Eric Blake eblake at redhat.com
Mon Mar 31 12:25:15 UTC 2014


On 03/31/2014 03:06 AM, Ján Tomko wrote:
> On 03/31/2014 02:42 AM, Cole Robinson wrote:
>> VolOpen notifies the user of a potentially non-fatal failure by
>> returning -2 and logging a VIR_WARN or VIR_INFO. Unfortunately most
>> callers treat -2 as fatal but don't actually report any message with
>> the error APIs.
>>
>> Change VolOpen to always report an error, and fix the one caller that
>> was actually handling -2 to explicitly unset the raised error. Tweak
>> some of the other call sites to properly propagate the newly raised
>> error.
>> ---
>> Unfortunately this makes libvirtd startup pretty noisy on stderr, since
>> logging is done at ErrorReport time, even if the error is never dispatched,
>> and every directory pool will try to probe the illegal volumes $target/. and
>> $target/.. . Suggestions welcome
>>
> 
> I think volOpen should report errors in all cases only if
> VIR_STORAGE_VOL_OPEN_ERROR is set (not only because we can't really unlog errors)
> 
> Every caller expect for virStorageBackendProbeTarget (where
> virStorageBackendFileSystemRefresh handles -2) has this flag set.

Agreed - either use flags to control whether to emit errors (so that the
one caller that cared about a -2 return uses different flags than the
others), or change the signature [or even both actions - VOL_OPEN_ERROR
flag AND a changed signature].  Right now, we have:

return value = -1, -2, or fd

but a signature more conducive to conditional error reporting might be:

caller passes int *fd
return value -1 (error issued), 0 (*fd == -1, but no error issued), or 1
(*fd >= 0)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140331/ecc512ab/attachment-0001.sig>


More information about the libvir-list mailing list