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 :|