All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Zhangjin <wuzhangjin@gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2 v2] ftrace: document basic ftracer/ftracer graph needs
Date: Mon, 15 Jun 2009 00:09:12 +0800	[thread overview]
Message-ID: <1244995752.31584.69.camel@falcon> (raw)
In-Reply-To: <8bd0f97a0906140845o73c4c9d6r40c2e1132a46fa6a@mail.gmail.com>

hi, Mike 

> >> +For information on how to implement prepare_ftrace_return(), simply look at
> >> +the x86 version.  The only architecture-specific piece in it is the setup of
> >> +the fault recovery table (the asm(...) code).  The rest should be the same
> >> +across architectures.
> >> +
> >
> > and the fault recovery table is not needed.
> 
> i dont have one for the Blackfin port, but that's more because there
> is no fault recovery support in the Blackfin port ;)
> 
> > In reality, the prepare_ftrace_return() can have the same arguments as
> > ftrace_trace_function()
> > ...
> > as i know, prepare_ftrace_return() is used to check whether the calling
> > function expect to trace, if yes, return the 'hook' function
> > &return_to_handler, otherwise, return back to the parent_ip directly.
> > so, here, i think there is no need to transfer the data via address, but
> > just using the same arguments like ftrace_trace_function does.
> 
> hmm, that would make the implementation simpler, but i dont think you
> could do that if you implemented the fault handler.  i cant really
> speak as to the requirement of the fault handler as i dont really know
> what/how it works -- i can only guess at they arent used in any way
> for Blackfin systems.
> 
> > unsigned long
> > prepare_ftrace_return(unsgined long ip, unsigned long parent_ip)
> > {
> >    [...]
> >    if (ftrace_push_return_trace(parent_ip, ip, &trace.depth) == -EBUSY)
> >        return parent_ip;
> >
> >    if (ftrace_graph_entry(&trace))
> >        return (unsigned long)&return_to_handler;
> >
> >    [...]
> >
> >    return parent_ip;
> > }
> >
> > if using the above method, the fault recovery table is not needed again.
> 
> and it would allow us to move this code into the common ftrace
> framework for people who dont do fault handlers.
> 

Perhaps I miss something here? otherwise, this fault handler is not
needed if not transfer the data via address and not modify the data in
the place *address accordingly.

best regards,
Wu Zhangjin


  reply	other threads:[~2009-06-14 16:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-10  8:48 [PATCH 1/2] ftrace.txt: fix typo in function grapher name Mike Frysinger
2009-06-10  8:48 ` [PATCH 2/2] ftrace: document basic ftracer/ftracer graph needs Mike Frysinger
2009-06-10 17:04   ` Steven Rostedt
2009-06-10 18:31     ` Mike Frysinger
2009-06-10 18:45       ` Steven Rostedt
2009-06-10 19:07         ` Mike Frysinger
2009-06-10 19:11           ` Steven Rostedt
2009-06-10 19:19             ` Mike Frysinger
2009-06-10 19:34               ` Steven Rostedt
2009-06-10 19:45                 ` Mike Frysinger
2009-06-10 18:56   ` Steven Rostedt
2009-06-10 20:52   ` [PATCH 2/2 v2] " Mike Frysinger
2009-06-12  8:10     ` Mike Frysinger
2009-06-13 22:24       ` Frederic Weisbecker
2009-06-14  0:21         ` [PATCH v3] " Mike Frysinger
2009-06-14  1:24           ` Frederic Weisbecker
2009-06-14  1:52             ` Mike Frysinger
2009-06-14  2:24               ` Frederic Weisbecker
2009-06-14  3:05             ` [PATCH v4] " Mike Frysinger
2009-06-14 13:35               ` Frederic Weisbecker
2009-06-23 12:30               ` Mike Frysinger
2009-06-23 13:43                 ` Ingo Molnar
2009-09-14  1:54                   ` Mike Frysinger
2009-09-14  2:35                     ` Steven Rostedt
2009-09-14 19:48               ` Steven Rostedt
2009-09-14 20:21                 ` Mike Frysinger
2009-09-14 20:53                   ` Steven Rostedt
2009-09-14 21:01                     ` Mike Frysinger
2009-09-14 21:20                       ` Steven Rostedt
2009-09-14 21:30                         ` Mike Frysinger
2009-09-14 21:41                           ` Steven Rostedt
2009-09-14 20:28                 ` Frederic Weisbecker
2009-09-15  0:10                 ` [PATCH v5] " Mike Frysinger
2009-09-15  1:48                   ` [PATCH] [GIT PULL] " Steven Rostedt
2009-09-17  7:47                   ` [tip:tracing/core] ftrace: document function and function graph implementation tip-bot for Mike Frysinger
2009-06-14 15:10     ` [PATCH 2/2 v2] ftrace: document basic ftracer/ftracer graph needs Wu Zhangjin
2009-06-14 15:45       ` Mike Frysinger
2009-06-14 16:09         ` Wu Zhangjin [this message]
2009-06-15  6:25           ` Mike Frysinger
2009-06-10 17:02 ` [PATCH 1/2] ftrace.txt: fix typo in function grapher name Steven Rostedt
2009-06-10 17:08 ` [PATCH][GIT PULL] ftrace/documentation: " Steven Rostedt
2009-06-10 22:33 ` [tip:tracing/core] " tip-bot for Mike Frysinger

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=1244995752.31584.69.camel@falcon \
    --to=wuzhangjin@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=vapier.adi@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.