mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Greg KH <greg@kroah.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC] tracefs
Date: Fri, 23 Oct 2009 09:12:08 -0400	[thread overview]
Message-ID: <1256303528.20866.822.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20091023053237.GA24359@elte.hu>

On Fri, 2009-10-23 at 07:32 +0200, Ingo Molnar wrote:

> _No way_ do we want to tie down the pretty-printing ftrace details as an 
> ABI. We promised that when ftrace went upstream and all the details are 
> way too messy to be exposed in an ABI alike matter (and yes, consider 
> this a NAK Steve ;-).

Note, I wasn't talking about tie down the pretty-print formats. But we
need to have a standard way to change them.

For example:

[root@mxf ~]# cat /debug/tracing/events/power/power_start/format 
name: power_start
ID: 258
format:
	field:unsigned short common_type;	offset:0;	size:2;
	field:unsigned char common_flags;	offset:2;	size:1;
	field:unsigned char common_preempt_count;	offset:3;	size:1;
	field:int common_pid;	offset:4;	size:4;
	field:int common_lock_depth;	offset:8;	size:4;

	field:u64 type;	offset:16;	size:8;
	field:u64 state;	offset:24;	size:8;

print fmt: "type=%lu state=%lu", (unsigned long)REC->type, (unsigned long)REC->state


Now we are going to add a "signed" field to each line. Fine, but we need
a spec of some sort to say how that will happen. Or what can be expected
to not change. We can say the type (field in this case) will always be
the first item, and that the type will stay on a single line. If the
parser does not know how to handle one of the items (offset, size, etc)
it can simply ignore it. When it hits the "\n", it is done with that
type.

We need to document this, so tools will not break when we update this
format.

-- Steve



  parent reply	other threads:[~2009-10-23 13:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-23  0:49 Greg KH
2009-10-23  1:10 ` Steven Rostedt
2009-10-23  4:27   ` Greg KH
2009-10-23  5:35   ` Ingo Molnar
2009-10-23  5:32 ` Ingo Molnar
2009-10-23  9:38   ` Frederic Weisbecker
2009-10-23 10:29     ` Ingo Molnar
2009-10-23 13:12   ` Steven Rostedt [this message]
2009-10-25  4:05     ` Christoph Hellwig
2009-10-28  1:06   ` Greg KH
2009-10-29  8:04     ` Ingo Molnar

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=1256303528.20866.822.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=fweisbec@gmail.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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®