> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index b749c01742ee..957415341caf 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -782,6 +782,13 @@ struct bpf_object {
> char *token_path;
> int token_fd;
>
> + /* kernel module BTFs to load, as specified via bpf_object_open_opts */
> + struct {
> + char **names;
> + size_t nr_names;
> + struct hashmap *names_map;
> + } *kmod_btfs;
> +
This isn't a bug, but since this holds module names rather than BTFs,
would a name like kmod_btf_filter read more clearly next to the existing
btf_modules field?
> char path[];
> };
[ ... ]
> @@ -5851,6 +5858,121 @@ int bpf_core_add_cands(struct bpf_core_cand
> *local_cand,
> return 0;
> }
>
> +static size_t mod_name_hash_fn(long key, void *ctx)
> +{
> + return str_hash((char *)key);
> +}
> +
> +static bool mod_name_equal_fn(long key1, long key2, void *ctx)
> +{
> + return strcmp((char *)key1, (char *)key2) == 0;
> +}
This isn't a bug, but these look identical to str_hash_fn()/str_equal_fn()
in btf_dump.c - would it be worth hoisting one copy into libbpf_internal.h
instead of adding a second pair?
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32236360082
