[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1274193698.26328.746.camel@gandalf.stny.rr.com>
Date: Tue, 18 May 2010 10:41:38 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: collecting static data related to tracing
On Tue, 2010-05-18 at 16:09 +0200, Johannes Berg wrote:
> I'm thinking that we could have per subsystem "detail" files that are
> provided by the respective subsystem implementation in some way, and can
> then simply be included in the recorded trace file. However, I have no
> idea if that is feasible to implement, or if maybe there's another way.
> FWIW, all my events already contain a pointer, used as a cookie, to
> identify the hardware instance, but that only allows me to read a trace
> that contains data about multiple devices, it doesn't give me
> information about each device. Ideally, the "detail" file would list all
> the information along with the cookie, so I could connect the dots.
>
> Thoughts?
The latest version of trace-cmd has an "options" section. This allows
you to add options to the file.
We could make a plugin that also can be used by trace-cmd record, that
allows you to add options. The options are written such that if a
trace-cmd does not know how to deal with them, they will be ignored.
Hmm, but the options require a unique ID. Well we could register IDs
with plugins, or add a plugin id, which uses the name of the plugin as
an identifier too.
But this would allow you to add the details you want about the system
and then have the reader be able to print it out.
How's that sound?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists