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

[Andreas Färber]

Am 04.04.2012 22:54, schrieb Peter Maydell:
> On 4 April 2012 21:34, Blue Swirl <address@hidden> wrote:
>> On Wed, Apr 4, 2012 at 20:11, Peter Maydell <address@hidden> wrote:
>>> 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.
> 
> Well, I looked at the docs and said "this gives me no benefit over
> DPRINTF, and why do I have to create a file that explicitly lists
> every single event the code I'm interested in has defined, and
> the quickstart seems to be recommending something that you have to
> postprocess, and generally I dunno what problem this is trying to
> solve but it doesn't look like it's trying to solve programmer debug
> tracing".
> 
> If other people want to write trace events that's fine but for me
> at the moment it seems a definite step back from simple DPRINTF
> macros.
> 
>>> 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.
> 
> (a) that gives you a binary dump rather than something actually
> readable (and 'simple' can't even handle string output!) and
> (b) if it's that good why don't we enable it by default?
> Also I can't see anything in the docs about having sensible sets
> of levels of tracing or grouping trace events into coherent sets
> you can toggle on and off.
> 
>> Processing is offline.
> 
> For debugging this is not a feature -- you want to see the output
> as you step through things in the debugger.

Seeing this thread today, not being cc'ed properly and the list lagging
yesterday once again, we should not have this discussion without
involving the tracing maintainer, cc'ed.

I agree with Blue that using tracepoints is more flexible output-wise
and avoids bitrot. However trace-events is an annoying single point of
merge conflicts when adding trace points. Is it thinkable of allowing
more localized tracepoint definitions

I agree with Peter that tracing being nop by default is not so helpful
for developers. So what about enabling the stderr backend by default,
with all tracepoints disabled by default?

In addition to what's been said on this thread, the simple tracing
backend potentially collects a lot of garbage into files that are hard
to post-process in a changing development tree due to dependency on
trace-events file.

I would've suggested to enable the platform's native tracing backend by
default, but on Linux there might be SystemTap and LTTng both present.
At least DTrace and SystemTap scripts can also emit printfs when events
occur, for DPRINTF-like output; shipping some examples for specific
areas in scripts/ might not be a bad idea either.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg