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