Re: [Patch -tip 3/3] Tracing/ftrace: Don't consume entries unhandled by mmiotrace

[Frédéric Weisbecker]

2008/9/25 Pekka Paalanen <pq@xxxxxx>:
> We can (must) return to this if/when multiple tracers are allowed
> to be active simultaneously. But in the current situation, I do not
> see a way to trace more than one thing, but I haven't really looked
> into the other tracers.

You can enable another tracer simultaneously. I never tried it but you can
launch one from debugfs and another from kernel code for example.
The new boot tracer will have to launch the sched_switch tracer.
And since the functions which display the sched_switch entries are
already inside
trace.c I wanted to relay the display to the "default display
functions". That's one of
the reason of my patch (+ the bug).
But I could proceed in a another way than default relaying. Why not
using a function exported
by the tracing engine to display sched_switches.

> but tracing functions is useless
> or harmful in the usual use case of mmiotrace, i.e. tracing a binary-only
> proprietary driver. The functions will be anonymous anyway, and we can't
> disassemble the driver due to possible legal reasons. That's why mmiotrace
> does not even collect instruction pointers by default, although it
> supports them (or did, can't recall if it works now, since it hasn't been
> needed). I assume the goal is to create a free open driver without any
> legal issues by watching what the proprietary driver does.
>
> Even if the log would be cluttered with MMIO from other, uninteresting
> drivers, you can use the physical address to filter the entries by
> device (and therefore driver) afterwards. This is one reason why
> an mmiotrace log starts with the contents of /proc/bus/pci/devices.
>
> Was there some other scenario you were thinking about?

When I wanted to help on the ath5k project, I used to compare madwifi
traces with the ath5k traces. The goal was to find where was the
trouble when support for ar2425 cards didn't worked.
And I wanted to see the name of the functions where the code entered
to see where I was in the traces. That's why I wanted to have
an mmiotrace_printk function primarily :)
But I think one could use it for debugging too. Just to know where we
are in the trace.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/