[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1339760011.13377.338.camel@gandalf.stny.rr.com>
Date: Fri, 15 Jun 2012 07:33:31 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Frederic Weisbecker <fweisbec@...il.com>,
yrl.pp-manager.tt@...achi.com
Subject: Re: [RFC][PATCH 05/13 v2] ftrace/x86: Add separate function to save
regs
On Fri, 2012-06-15 at 17:15 +0900, Masami Hiramatsu wrote:
> > It is OK for an arch to pass NULL regs. All function trace users that
> > require regs passing must add the flag FTRACE_OPS_FL_SAVE_REGS when
> > registering the ftrace_ops and either check if regs is not NULL or
> > check if ARCH_SUPPORTS_FTRACE_SAVE_REGS. If the arch supports passing
> > regs it will set this macro and pass regs for ops that request them.
> > All other archs will just pass NULL.
>
> Hmm, so would you mean that user is responsible for checking
> whether the arch supports save_regs or not?
> I would rather like ftrace to check it as my patch has done.
> I think ARCH_SUPPORTS_FTRACE_SAVE_REGS macro checking in all
> handler code is something like odd...
I was thinking of routines that may or may not use regs. Actually, I was
thinking about perf in general, that could use regs if supported, or get
its own set.
But I agree that it may not be the best for those that must have regs.
Perhaps we could add another flag:
FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED
Where it wont error out if you have this set. But if you just pass in
FTRACE_OPS_FL_SAVE_REGS (as kprobes does) it will fail.
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