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

[Pekka Paalanen <pq@iki.fi>]

On Thu, 25 Sep 2008 16:44:08 +0200
"Frédéric Weisbecker" <fweisbec@gmail.com> wrote:

> 2008/9/25 Pekka Paalanen <pq@iki.fi>:
> > 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.
> 
> 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..?)

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/