When mmiotrace can't handle an entry output, it returns 1.
It should return 0 to relay on other output functions.

Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
---
[ message continues ]

applied to tip/tracing/mmiotrace, thanks Frédéric!

	Ingo
--

[ message continues ]

On Thu, 25 Sep 2008 13:28:56 +0100

NACK.

mmiotrace's log output is stricly specified, the standard/default
printing functions may NOT be used. The output is supposed to be
machine readable in addition to human readable.

The ftrace infrastructure assumes there is only one active tracer
at a time, therefore destroying unhandled entries is not a problem.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--

[ message continues ]

Hi Pekka.

It's up to you.
I just guessed that one would trace IO and stack for example.
Or why not IO and functions: This sounds to me very useful (who
performed this io..?)

As you want....

Regards...
--

[ message continues ]

On Thu, 25 Sep 2008 16:44:08 +0200

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.

OTOH, mmiotrace log format has a pid field, which is pretty much unused
currently. It could be used to record the current process, if one exists.
That can be added, should the need arise, but so far the field has been
reserved for tracing accesses done in user space - but those are not
caught yet.

I'm not sure what stack trace collects, 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?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--

[ message continues ]

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

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

[ message continues ]

hm, right now i can see a lot of problems with that approach - the 
buffers are partly per tracer and partly global.

the new trace-ringbuffer design Steve is working on would abstract away 
this complication - then we could make tracers truly independent 
entities.

	Ingo
--

[ message continues ]