[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20241001004307.bc238bbda81907c08a8c1e96@kernel.org>
Date: Tue, 1 Oct 2024 00:43:07 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Tiezhu Yang <yangtiezhu@...ngson.cn>,
linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Question about config UPROBES and UPROBE_EVENTS
On Mon, 30 Sep 2024 11:32:31 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> On Tue, 1 Oct 2024 00:28:13 +0900
> Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
>
> > On Mon, 30 Sep 2024 10:06:30 -0400
> > Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > > On Mon, 30 Sep 2024 09:33:42 +0800
> > > Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
> > >
> > > > > the CONFIG_UPROBES is disabled by default and make CONFIG_UPROBE_EVENTS
> > > > > depending on it, the uprobe_events menu is hidden. I don't like this.
> > > >
> > > > This is somehow like the current status of CONFIG_KPROBES and
> > > > CONFIG_KPROBE_EVENTS.
> > >
> > > The question is, can uprobes be used without uprobe_events? With the
> > > current BPF work that I haven't been following, it may be possible now.
> >
> > uprobe_register/unregister APIs are exposed to the kernel modules,
> > since systemtap had been introduced this feature.
> >
>
> OK, but since they have always been visible, I would just make
> CONFIG_UPROBES a normal option and CONFIG_UPROBE_EVENTS select it if it
> gets selected, and not depend on it.
Agreed.
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists