On Mon, Dec 10, 2012 at 10:19:35AM +0000, Daniel P. Berrange wrote:
On Sat, Dec 08, 2012 at 08:48:55PM -0500, Cole Robinson wrote:
> API users won't have any way to interact with the errors since this is
> before a connection pointer is available, but the default error handler
> at calls VIR_ERROR which gives us a better chance of seeing the issue.
> ---
> src/libvirt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/libvirt.c b/src/libvirt.c
> index 6a7a817..5f8b087 100644
> --- a/src/libvirt.c
> +++ b/src/libvirt.c
> @@ -813,6 +813,7 @@ int virStateInitialize(bool privileged,
> if (virStateDriverTab[i]->initialize(privileged,
> callback,
> opaque) < 0) {
> + virDispatchError(NULL);
> VIR_ERROR(_("Initialization of %s state driver failed"),
> virStateDriverTab[i]->name);
> return -1;
Hmm, I kind of thing libvirtd should be the one doing this in
its exit paths. Many (all) of the APIs libvirtd uses can raise
errors, and we want them disptched if it exits.
Actually having said that, I believe we don't need todo anything.
The virDispatchError() function is concerned with invoking the registered
error callback, which libvirtd has already disabled. The logging of errors
via VIR_ERROR is done at the point they are reported with virRaiseError.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|