On Wed, May 02, 2007 at 08:15:11AM -0400, Daniel Veillard wrote: > On Tue, May 01, 2007 at 03:04:32PM +0100, Richard W.M. Jones wrote: > > Error messages, I like them. I don't like them to be thrown away. > > > > A nice feature of virterror is that it'll throw away errors under the > > following conditions: > > (1) You are in virConnectOpen, and > > (2) You pass a non-NULL virConnectPtr to __virRaiseError. > > > > libvirt has a lot of errors which meet those conditions - the attached > > patch fixes the ones I could find. > > > > It also fixes qemuOpenConnection so that it doesn't try to open a Unix > > socket with random stack data. > > > > It also adds error messages in some useful places where previously there > > was an error, but no message. > > In general that looks okay, but instead of passing NULL as the first > argument can't we do a selection in __virRaiseError instead based on the > type of error and just avoid virConnectOpen errors which are not related to > unavailability of the virtualization ? That doesn't make sense to me. The issue here is that libvirt has two places where it stores error details for the caller: - The global error object - The per-connection error object If the virConnectOpen call fails, then the caller has no virConnectPtr object available. So every codepath in virConnectOpen should be using the global error object & hence always be passing NULL to __virRaiseError. So I think Rich's patch is already doing the correct thing AFAICT Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|