From: Steven Rostedt <rostedt@goodmis.org>
To: Hou Tao <houtao1@huawei.com>
Cc: Hou Tao <hotforest@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>, Yonghong Song <yhs@fb.com>,
Martin KaFai Lau <kafai@fb.com>, Ingo Molnar <mingo@redhat.com>,
<netdev@vger.kernel.org>, <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v5 0/3] add support for writable bare tracepoint
Date: Mon, 11 Oct 2021 10:34:42 -0400 [thread overview]
Message-ID: <20211011103442.2ce9fab7@gandalf.local.home> (raw)
In-Reply-To: <0147c4ea-773a-5fe9-dea5-edd16ad1db12@huawei.com>
On Sat, 9 Oct 2021 20:07:10 +0800
Hou Tao <houtao1@huawei.com> wrote:
> Not tried yet, but considering that VFS maintainer refused to have tracepoint in
> VFS layer, I'm not sure it is worth trying.
The reason they refuse to is because it shows data that can become an API.
But if that data is just a pointer, then it's not possible to become an API
no more than a RAW tracepoint that BPF can hook to.
Try asking.
> >
> > That is, it only gives you a pointer to what is passed in, but does not
> > give you anything else to form any API against it.
> > This way, not only does BPF have access to this information, so do the
> > other tracers, through the new eprobe interface:
> Or in a opposite way can eprobe add support for bare tracepoint ?
If there's a way to expose the parameters of a bare tracepoint, then it
should not be difficult to do so. Heck, we can just have "bare tracepoints"
be events, that do nothing but repeat their pointer parameters, as that's
basically all they do anyway. There's nothing fundamentally different
between a "bare tracepoint" and a trace event that just defines the fields
as the same as the parameters to a tracepoint, except now you have another
way to know what the parameters are.
-- Steve
next prev parent reply other threads:[~2021-10-11 14:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 9:48 [PATCH bpf-next v5 0/3] add support for writable bare tracepoint Hou Tao
2021-10-04 9:48 ` [PATCH bpf-next v5 1/3] bpf: support writable context for " Hou Tao
2021-10-04 9:48 ` [PATCH bpf-next v5 2/3] libbpf: support detecting and attaching of writable tracepoint program Hou Tao
2021-10-04 9:48 ` [PATCH bpf-next v5 3/3] bpf/selftests: add test for writable bare tracepoint Hou Tao
2021-10-04 14:46 ` [PATCH bpf-next v5 0/3] add support " Steven Rostedt
2021-10-09 12:07 ` Hou Tao
2021-10-11 14:34 ` Steven Rostedt [this message]
2021-10-08 20:40 ` patchwork-bot+netdevbpf
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=20211011103442.2ce9fab7@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hotforest@gmail.com \
--cc=houtao1@huawei.com \
--cc=kafai@fb.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=yhs@fb.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.