Re: [Qemu-devel] [PATCH 3/3] pseries: Add DPRINTF macros to spapr pci code

[Blue Swirl]

On Wed, Apr 4, 2012 at 20:11, Peter Maydell <address@hidden> wrote:
> On 4 April 2012 20:18, Blue Swirl <address@hidden> wrote:
>> On Mon, Apr 2, 2012 at 04:17, David Gibson <address@hidden> wrote:
>>> From: Alexey Kardashevskiy <address@hidden>
>>> This adds DPRINTF() macros with the usual conventions to the spapr_pci
>>> code.
>>
>> Please use tracepoints instead of printf statements. Tracing is more
>> flexible, more efficient and does not suffer from bitrot.
>
> I'd much rather enable a #define to turn on debugging than faff about
> with tracing. It's simple and straightforward, you can do it with a
> single obvious change and recompile, and nobody has to look up
> documentation to figure out how it works.

Laziness. Even the built in help should be sufficient to start using
tracepoints.

> If tracepoints were always-compiled-in and enabled at runtime I'd
> agree with you: then you could have linux-kernel-style "enable debug
> tracing", "enable warnings about odd guest behaviour", "be silent",
> etc. But they're not, so they don't gain anything over a simple
> DPRINTF for programmer debugging.

False. It's easy to compile in tracepoints
(--enable-trace-backend=simple) and the overhead is zero or marginal.
It's not possible to enable or disable DPRINTFs at run time easily
which is trivial with tracepoints. When the tracepoints are enabled,
due to binary format they are faster than text output.  There's no
need to relink the files when triggering on and off tracepoints. Trace
files are much more compact than text. Processing is offline. Delta
timestamps are provided. Tracepoints do not suffer from bitrot. From
programming standpoint, DPRINTF is changed to a function call and the
format text is put to a different file, that's it.

Have you ever waded through hundreds of megabytes of DPRINTF stuff or
other logs, 99.99999% (literally, only a few bytes were interesting!)
of it not what you want, just because the interesting stuff happens to
be near to end of it? Even 'vi' is slow when handling these kind of
files.

Just for fun, try also enabling all DPRINTFs (small sed script
exercise left to reader) and see how many breakages there are due to
bit rotted DPRINTFs.

>
> -- PMM