On 01/04/2011 08:30 AM, Daniel P. Berrange wrote:
>> virDomainGetConnect (virDomainPtr dom)
>> {
>> - DEBUG("dom=%p", dom);
>> + const char *name = virDomainGetName(dom);
>> +
>> + DEBUG("dom=%p, (VM: %s)", dom, NULLSTR(name));
>
> Calling virDomainGetName() which is also a public API will pollute
> the logs with messages about virDomainGetName being invoked, every
> time.
So my fear about potential deadlock from invoking one public API from
within another was not quite right, but I was on the right track of
being worried about the use of a public API for debug purposes, because
it does introduce log pollution. If this is the only problem, then a
possible solution would be to use a private API for getting the name for
logging purposes.
> Logging the name alone is also potentially misleading, since
> most of the API impls use the UUID and ignore the name.
Then maybe the patch should be altered to output both name and UUID
(probably by introducing a helper function, which when given a
virDomainPtr outputs all three pieces of debug information rather than
the current %p). I like the idea behind the patch, but only if we can
come up with the correct way of getting the extra information when
debugging is enabled, and without adding extra time when debugging is
off. I'm not even sure what the right internal APIs for the job would
be, or if they even exist yet.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list