On Mon, Sep 6, 2021 at 9:55 AM Hengqi Chen <hengqi.chen@xxxxxxxxx> wrote:
>
> Deprecate bpf_{map,program}__{prev,next} APIs. Replace them with
> a new set of APIs named bpf_object__{prev,next}_{program,map} which
> follow the libbpf API naming convention. No functionality changes.
>
> Closes: https://github.com/libbpf/libbpf/issues/296
I'm hesitant about using Closes: as if it was a proper Linux tag.
Let's stick to using it in a reference:
[0] Closes: ...
> Signed-off-by: Hengqi Chen <hengqi.chen@xxxxxxxxx>
> ---
> tools/lib/bpf/libbpf.c | 24 ++++++++++++++++++------
> tools/lib/bpf/libbpf.h | 30 ++++++++++++++++++++----------
> tools/lib/bpf/libbpf.map | 4 ++++
> 3 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 88d8825fc6f6..8d82853fb4a0 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -7347,7 +7347,7 @@ int bpf_object__pin_maps(struct bpf_object *obj, const char *path)
> return 0;
>
> err_unpin_maps:
> - while ((map = bpf_map__prev(map, obj))) {
> + while ((map = bpf_object__prev_map(map, obj))) {
> if (!map->pin_path)
> continue;
>
> @@ -7427,7 +7427,7 @@ int bpf_object__pin_programs(struct bpf_object *obj, const char *path)
> return 0;
>
> err_unpin_programs:
> - while ((prog = bpf_program__prev(prog, obj))) {
> + while ((prog = bpf_object__prev_program(prog, obj))) {
> char buf[PATH_MAX];
> int len;
>
> @@ -7666,8 +7666,11 @@ __bpf_program__iter(const struct bpf_program *p, const struct bpf_object *obj,
> return &obj->programs[idx];
> }
>
> +__attribute__((alias("bpf_object__next_program")))
> +struct bpf_program *bpf_program__next(struct bpf_program *prev, const struct bpf_object *obj);
> +
> struct bpf_program *
> -bpf_program__next(struct bpf_program *prev, const struct bpf_object *obj)
> +bpf_object__next_program(struct bpf_program *prev, const struct bpf_object *obj)
I think for bpf_object__next_program it makes more sense to have obj
as the first argument (it's a "method" of bpf_object, after all). So
you can't have bpf_program__next aliased to bpf_object__next_program,
you have to add a small wrapper function. Same for other new APIs.
> {
> struct bpf_program *prog = prev;
>
> @@ -7678,8 +7681,11 @@ bpf_program__next(struct bpf_program *prev, const struct bpf_object *obj)
> return prog;
> }
>
[...]
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index f177d897c5f7..e6aab4cd263b 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -186,16 +186,22 @@ LIBBPF_API int libbpf_find_vmlinux_btf_id(const char *name,
>
> /* Accessors of bpf_program */
> struct bpf_program;
> -LIBBPF_API struct bpf_program *bpf_program__next(struct bpf_program *prog,
> +LIBBPF_API LIBBPF_DEPRECATED("bpf_program__next() is deprecated, use bpf_object__next_program() instead")
We shouldn't deprecate API until the replacement API was already
released as part of an official libbpf release. I suggest to wait
until the LIBBPF_DEPRECATE_SINCE ([0]) patch lands first, and then
using that here to deprecate those APIs starting from 0.7 (because we
are now developing 0.6 libbpf).
[0] https://patchwork.kernel.org/project/netdevbpf/patch/20210908213226.1871016-1-andrii@xxxxxxxxxx/
> +struct bpf_program *bpf_program__next(struct bpf_program *prog,
> const struct bpf_object *obj);
> +LIBBPF_API struct bpf_program *bpf_object__next_program(struct bpf_program *prog,
> + const struct bpf_object *obj);
>
[...]
> /* get/set map FD */
> LIBBPF_API int bpf_map__fd(const struct bpf_map *map);
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index bbc53bb25f68..0c6d510e7747 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -378,6 +378,10 @@ LIBBPF_0.5.0 {
> bpf_program__attach_tracepoint_opts;
> bpf_program__attach_uprobe_opts;
> bpf_object__gen_loader;
> + bpf_object__next_map;
> + bpf_object__next_program;
> + bpf_object__prev_map;
> + bpf_object__prev_program;
For next revision, please add the LIBBPF_0.6.0 section, libbpf 0.5 was
just released today, so we are now moving into the v0.6 development
cycle. Thanks!
> btf__load_from_kernel_by_id;
> btf__load_from_kernel_by_id_split;
> btf__load_into_kernel;
> --
> 2.30.2
