From: Steven Rostedt <rostedt@goodmis.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: collecting static data related to tracing
Date: Tue, 18 May 2010 10:41:38 -0400 [thread overview]
Message-ID: <1274193698.26328.746.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <1274191742.31554.10.camel@jlt3.sipsolutions.net>
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
next prev parent reply other threads:[~2010-05-18 14:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-18 14:09 Johannes Berg
2010-05-18 14:41 ` Steven Rostedt [this message]
2010-05-18 14:45 ` Johannes Berg
2010-05-19 7:28 ` Frederic Weisbecker
2010-05-19 8:15 ` Johannes Berg
2010-05-19 14:44 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1274193698.26328.746.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®