On Mon, Oct 15, 2012 at 08:43:44AM +0100, Richard W.M. Jones wrote:
On Sun, Oct 14, 2012 at 07:57:02PM -0400, Cole Robinson wrote:
> On 10/14/2012 01:52 PM, Richard W.M. Jones wrote:
> >
> > Well, it was a good idea, but the patch doesn't work. Apparently
> > along their open paths, drivers don't set errors in the newly created
> > handle, but in the global handler instead (hence the errors still get
> > printed to stderr).
> >
>
> Can you give an example of the error you are seeing?
I was one of the libssh errors, I don't have the exact text.
> I don't think I've ever
> experienced that issue with virt-install/virt-manager. You can use
> virSetErrorFunc before getting a virConnect handle.
You can do this in a program, but not in a library (like libguestfs)
because it changes the global handler, which the program using the
library might not be happy about.
Doing it on a thread-local basis might work, but AFAICT from the
source, only the error messages (not the handler) are thread-local.
The error function callbacks in libvirt are rather horrible things
that I wish we never had. I agree that libraries should not be
explicitly setting it to a value of their owning choosing since
that would override a setting an app might have made.
I would think we could at least allow an env variable to turn
off use of the default though. eg we could allow anyone to do
export LIBVIRT_DEFAULT_ERROR_PRINT=0
and this would stop all use of virDefaultErrorFunc globally. THen
libguestfs could set this env var, but apps would still be able to
set a custom error function if they desired.
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 :|