[v2 bpf-next rebased] bpf: use canonical ftrace path #4672
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The canonical location for the tracefs filesystem is at /sys/kernel/tracing. But, from Documentation/trace/ftrace.rst: Before 4.1, all ftrace tracing control files were within the debugfs file system, which is typically located at /sys/kernel/debug/tracing. For backward compatibility, when mounting the debugfs file system, the tracefs file system will be automatically mounted at: /sys/kernel/debug/tracing Many comments and samples in the bpf code still refer to this older debugfs path, so let's update them to avoid confusion. There are a few spots where the bpf code explicitly checks both tracefs and debugfs (tools/bpf/bpftool/tracelog.c and tools/lib/api/fs/fs.c) and I've left those alone so that the tools can continue to work with both paths. Signed-off-by: Ross Zwisler <zwisler@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
The canonical location for the tracefs filesystem is at /sys/kernel/tracing. But, from Documentation/trace/ftrace.rst: Before 4.1, all ftrace tracing control files were within the debugfs file system, which is typically located at /sys/kernel/debug/tracing. For backward compatibility, when mounting the debugfs file system, the tracefs file system will be automatically mounted at: /sys/kernel/debug/tracing Many tests in the bpf selftest code still refer to this older debugfs path, so let's update them to avoid confusion. Signed-off-by: Ross Zwisler <zwisler@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com>
kernel-patches-bot
force-pushed
the
bpf-next_base
branch
8 times, most recently
from
c3b7bfa
to
79367ef
Compare
|
Hello! I just noticed that it doesn't look like the CI jobs for this pull request have been kicked off. Do you need anything else from my side? Also, was there a better way to re-submit this PR to the CI infra (previously at #4648) or was creating a new PR that was rebased the correct thing? I'm really curious if the failures were from some other CL or were just flake - I can't repo them locally, and don't immediately see how they could be due to my changes. Thanks! |
kernel-patches-bot
force-pushed
the
bpf-next_base
branch
8 times, most recently
from
6a992f8
to
55d99d5
Compare
|
Automatically cleaning up stale PR; feel free to reopen if needed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previous PR: #4648
Resbumitting this PR after rebasing to the current bpf-next_base.
v1: https://lore.kernel.org/bpf/Y+u1lL49CB86VSuE@google.com/T/
Changes since v1:
Rebased onto bpf-next
Added fallback paths so that both tracefs and debugfs will be tried in all selftests.
Ran and passed all bpf selftests locally using both tracefs and debugfs.