[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FDEF191.7000009@hitachi.com>
Date: Mon, 18 Jun 2012 18:14:57 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: Steven Rostedt <rostedt@...dmis.org>
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
(2012/06/15 20:33), Steven Rostedt wrote:
> 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?
Yeah, that's good for me. :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
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