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

[Blue Swirl]

On Thu, Apr 5, 2012 at 12:24, Andreas Färber <address@hidden> wrote:
> 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

Forgot to respond to this, sorry. I think this could be useful.

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

Maybe the best would be that several back ends could be enabled at the
same time.

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

What is this garbage?

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

Yes, I've never tried either because simpletrace works for me and I
haven't seen simple examples for them.

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