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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list