tools: introduce path helpers and filelife,filegone support file path

[Rtoax]

Do the same thing #5340 to tools.

add

• tools/path_helpers.bpf.c: add bpf helpers to get full-path from dentry;
• tools/path_helpers.py: to parse full-path in userspace with python;
• tools/full_path.h: define C full-path struct/macro;

filelife,filegone

• use ring-buffer instead of perf-buffer;
• support full-path with -F argument;

[Rtoax]

Rebase to master.

[ekyooo]

I have a few questions about the overall structure first.

1. Is the use of bpf_map_ringbuf mandatory for path_helper?

2. If not mandatory, can we split the application commits for each tool (e.g., filegone, filelife) into two separate changes?
   (1) One commit for replacing the perf buffer map with the ring buffer map
   (2) Another commit for actually applying path_helper
   I believe separating the structural (infrastructure) change (ring buffer migration) from the functional change (full-path helper adoption) would make the history easier to manage and help with future maintenance. Also, having a dedicated commit for path_helper integration will serve as a clear reference for other developers who may want to apply it to additional tools later.

3. Would it be possible to separate the application of path_helper to opensnoop into its own commit? The first commit is quite large, so splitting out the path_helper integration—similar to what was done for the other tools—would make the code easier to review and understand.

4. Is there a specific reason for using -F (full-path) instead of -P/--path? Personally, when I see the -F option, it’s not immediately clear that it refers to “path output,” and the meaning of “F” isn’t very intuitive. I’m curious about the reasoning behind this choice.

Thank you.

[Rtoax]

@ekyooo There are 6 commits ( minimize code modifications per commit )

1. Introduce path_helpers (without modifying opensnoop.py)
2. Modify opensnoop.py
3. filelife perf-buffer replaced with ring-buffer (required, ringbuffer_reserve required)
4. filelife implementation file path (-P)
5. Replace perf-buffer of fileone with ring-buffer (required, ringbuffer_reserve required)
6. filebone implementation file path (-P)

Please review the code again, thank you

[Rtoax]

rebase to master

[ekyooo]

Is the use of bpf_map_ringbuf mandatory for path_helper?

Could you answer my question with clear reasoning?

To clarify the buffer type in #5340:

1. You used compat.h in filelife, which provides compatibility between perf buffer and ring buffer.
2. You stated in the commit message that you replaced perf buffer with ring buffer.
3. What is true?

The use of the ring buffer is a modern change, but it excludes users of kernel versions below 5.8.
Should we reduce the tool's overall usability for an optional feature?
Before deciding, I need to verify the justification for this change.

[Rtoax]

Is the use of bpf_map_ringbuf mandatory for path_helper?

Could you answer my question with clear reasoning?

To clarify the buffer type in #5340:

1. You used compat.h in filelife, which provides compatibility between perf buffer and ring buffer.

2. You stated in the commit message that you replaced perf buffer with ring buffer.

3. What is true?

Thanks for your reply, the #5340 is for libbpf-tools/, this PR for tools/, those are different. This PR only replace perfbuffer with ring buffer.

The use of the ring buffer is a modern change, but it excludes users of kernel versions below 5.8. Should we reduce the tool's overall usability for an optional feature? Before deciding, I need to verify the justification for this change.

Indeed, thanks, you're right, maybe we should introduce compat.h like method for tools/ ?

[ekyooo]

I have a question: was perf_buffer also verified to work correctly in PR #5340?

If so, I think it would be beneficial to apply compat.h to the Python tools as well. Even without using path_helper, this change would likely benefit multiple tools. Thanks!

[Rtoax]

Thank you for your reply, I will confirm this ;)

[Rtoax]

I have a question: was perf_buffer also verified to work correctly in PR #5340?

Sorry about the late reply, i tried this change, it's not works.

diff --git a/libbpf-tools/compat.c b/libbpf-tools/compat.c
index 7d932ef30591..31065e178984 100644
--- a/libbpf-tools/compat.c
+++ b/libbpf-tools/compat.c
@@ -35,7 +35,7 @@ struct bpf_buffer *bpf_buffer__new(struct bpf_map *events, struct bpf_map *heap)
        bool use_ringbuf;
        int type;
 
-       use_ringbuf = probe_ringbuf();
+       use_ringbuf = 0;
        if (use_ringbuf) {
                bpf_map__set_autocreate(heap, false);
                type = BPF_MAP_TYPE_RINGBUF;

$ sudo ./filelife 
libbpf: map 'events': failed to create: -EINVAL
libbpf: failed to load BPF skeleton 'filelife_bpf': -EINVAL
failed to load BPF object: -22