On Wed, 22 May 2019 16:30:21 +0900
Masami Hiramatsu wrote:
> On Wed, 22 May 2019 00:39:32 +0900
> Masami Hiramatsu wrote:
>
> > > Perhaps we could enable kprobes at early init?
> >
> > It should be possible, I will try to find what blocks it. I guess after we
> > switch early_text_poke() to te
On Wed, 22 May 2019 00:39:32 +0900
Masami Hiramatsu wrote:
> > Perhaps we could enable kprobes at early init?
>
> It should be possible, I will try to find what blocks it. I guess after we
> switch early_text_poke() to text_poke(), we can use kprobes on x86. But
> for other archs, I need to inve
On Tue, 21 May 2019 09:33:17 -0400
Steven Rostedt wrote:
> On Tue, 21 May 2019 16:56:16 +0900
> Masami Hiramatsu wrote:
>
> > Note that 'trace_event=' option enables trace event at very early
> > timing, but the events added by 'kprobe_event=' are enabled right
> > before enabling device driver
On Tue, 21 May 2019 16:56:16 +0900
Masami Hiramatsu wrote:
> Note that 'trace_event=' option enables trace event at very early
> timing, but the events added by 'kprobe_event=' are enabled right
> before enabling device drivers at this point. It is enough for
> tracing device driver initializatio
This series adds a kernel parameter, 'kprobe_event=' to add and enable
new kprobe events at boot time.
Currently ftrace can enable some existing trace events at boot time.
This also allows admin/developer to add new kprobe-events at boot
time to debug device drivers etc.
The syntax is similar to
