Re: [Qemu-devel] [RFC][PATCH v3 03/21] virtproxy: add debug functions for virtproxy core

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Nov 18, 2010 at 11:09 AM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 11/16/10 02:15, Michael Roth wrote:
>> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
>> ---
>>  virtproxy.c |   17 +++++++++++++++++
>>  1 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/virtproxy.c b/virtproxy.c
>> index 8f18d83..3686c77 100644
>> --- a/virtproxy.c
>> +++ b/virtproxy.c
>> @@ -13,6 +13,23 @@
>>
>>  #include "virtproxy.h"
>>
>> +#define DEBUG_VP
>> +
>> +#ifdef DEBUG_VP
>> +#define TRACE(msg, ...) do { \
>> +    fprintf(stderr, "%s:%s():L%d: " msg "\n", \
>> +            __FILE__, __FUNCTION__, __LINE__, ## __VA_ARGS__); \
>> +} while(0)
>> +#else
>> +#define TRACE(msg, ...) \
>> +    do { } while (0)
>> +#endif
>> +
>> +#define LOG(msg, ...) do { \
>> +    fprintf(stderr, "%s:%s(): " msg "\n", \
>> +            __FILE__, __FUNCTION__, ## __VA_ARGS__); \
>> +} while(0)
>> +
>
> I wonder if it wouldn't make sense to do this in a more generic way and
> stick it in a header file. This type of debug code seems to show up
> repeatedly all over the place.

I wanted to suggest actually using QEMU tracing but given that this
code compiles stand-alone, it may be more trouble to integrate than
it's worth.

For qemu and qemu-tools code we should be using tracing because you
can build it into production without high overhead.  How often do
these #defines get used, not often is my guess because no one wants to
tweak the source and rebuild, especially not in production.

Stefan