All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Monnet <quentin@isovalent.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 0/5] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF
Date: Wed, 28 Jul 2021 22:54:22 +0100	[thread overview]
Message-ID: <CACdoK4+HCt6+70rKsWuwqMkuOGGcUPCgretnVp430gb_mWpUQw@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzZ8wXhpRwPkBmH3i94oVea2BucC56PCK-0j4N_3gk29Ng@mail.gmail.com>

On Tue, 27 Jul 2021 at 21:49, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:

> > >>>
> > >>> LIBBPF_DEPRECATED_SINCE(0, 6, "API that will be marked deprecated in v0.6")
> >
> > So I've been looking into this, and it's not _that_ simple to do. Unless
> > I missed something about preprocessing macros, I cannot bake a "#if" in
> > a "#define", to have the attribute printed if and only if the current
> > version is >= 0.6 in this example.
> >
> > I've come up with something, but it is not optimal because I have to
> > write a check and macros for each version number used with the
> > LIBBPF_DEPRECATED_SINCE macro. If we really wanted to automate that part
> > I guess we could generate a header with those macros from the Makefile
> > and include it in libbpf_common.h, but that does not really look much
> > cleaner to me.
>
> Yeah, let's not add unnecessary code generation. It sucks, of course,
> that we can't do #ifdef inside a macro :(
>
> So it's either do something like what you did with defining
> version-specific macros, which is actually not too bad, because it's
> not like we have tons of those versions anyways.
>
> LIBBPF_DEPRECATED_SINCE(0, 6, "use btf__load_from_kernel_by_id instead")
> LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
>
> Alternatively, we can go with:
>
> #if LIBBPF_AT_OR_NEWER(0, 6)
> LIBBPF_DEPRECATED("use btf__load_from_kernel_by_id instead")
> #endif
> LIBBPF API int btf__get_from_id(__u32 id, struct btf **btf);
>
> I don't really dislike the second variant too much either, but
> LIBBPF_DEPRECATED_SINCE() reads nicer. Let's go with that. See some
> comments below about implementation.

Ok.

>
> >
> > Here's my current code, below - does it correspond to what you had in
> > mind? Or did you think of something else?
> >
> > ------
> >
> > diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> > index ec14aa725bb0..095d5dc30d50 100644
> > --- a/tools/lib/bpf/Makefile
> > +++ b/tools/lib/bpf/Makefile
> > @@ -8,6 +8,7 @@ LIBBPF_VERSION := $(shell \
> >         grep -oE '^LIBBPF_([0-9.]+)' libbpf.map | \
> >         sort -rV | head -n1 | cut -d'_' -f2)
> >  LIBBPF_MAJOR_VERSION := $(firstword $(subst ., ,$(LIBBPF_VERSION)))
> > +LIBBPF_MINOR_VERSION := $(firstword $(subst ., ,$(subst $(LIBBPF_MAJOR_VERSION)., ,$(LIBBPF_VERSION))))
>
> Given all this is for internal use, I'd instead define something like
> __LIBBPF_CURVER as an integer that is easy to compare against:
>
> #define __LIBBPF_CURVER (LIBBPF_MAJOR_VERSION * 100 +
> LIBBPF_MINOR_VERSION) * 100 + LIBBPF_PATCH_VERSION
>
> That will simplify some stuff below and is generally easier to use in
> code, if we will need this somewhere to use explicitly.

Did you mean computing __LIBBPF_CURVER in the Makefile, or in the
header?

I can do that if you want, although I'm not convinced it will simplify
much. Instead of having one long-ish condition, we'll have to compute
the integer for the current version, as well as for each of the versions
that we list for deprecating functions. I suppose I can add another
dedicated macro.

Do you actually want the patch version? I chose to leave it aside
because 1) I thought it would not be relevant for deprecating symbols,
and 2) if anything like a -rc1 suffix is ever appended to the version,
it makes it more complex to parse from the version string.

>
> >
> >  MAKEFLAGS += --no-print-directory
> >
> > @@ -86,6 +87,8 @@ override CFLAGS += -Werror -Wall
> >  override CFLAGS += $(INCLUDES)
> >  override CFLAGS += -fvisibility=hidden
> >  override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> > +override CFLAGS += -DLIBBPF_MAJOR_VERSION=$(LIBBPF_MAJOR_VERSION)
> > +override CFLAGS += -DLIBBPF_MINOR_VERSION=$(LIBBPF_MINOR_VERSION)
> >
> >  # flags specific for shared library
> >  SHLIB_FLAGS := -DSHARED -fPIC
> > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > index cf8490f95641..8b6b5442dbd8 100644
> > --- a/tools/lib/bpf/btf.h
> > +++ b/tools/lib/bpf/btf.h
> > @@ -45,7 +45,8 @@ LIBBPF_API struct btf *btf__parse_raw(const char *path);
> >  LIBBPF_API struct btf *btf__parse_raw_split(const char *path, struct btf *base_btf);
> >  LIBBPF_API struct btf *btf__load_from_kernel_by_id(__u32 id);
> >  LIBBPF_API struct btf *btf__load_from_kernel_by_id_split(__u32 id, struct btf *base_btf);
> > -LIBBPF_API int btf__get_from_id(__u32 id, struct btf **btf);
> > +LIBBPF_API LIBBPF_DEPRECATED_SINCE(0, 6, "use btf__load_from_kernel_by_id instead")
>
> nit: given how long those deprecations will be, let's keep them at a
> separate (first) line and keep LIBBPF_API near the function
> declaration itself

I thought having the LIBBPF_API on a separate line would slightly reduce
the risk, when moving lines around, to move the function prototype but
not the deprecation attribute. But ok, fine.

>
> > +int btf__get_from_id(__u32 id, struct btf **btf);
> >
> >  LIBBPF_API int btf__finalize_data(struct bpf_object *obj, struct btf *btf);
> >  LIBBPF_API int btf__load(struct btf *btf);
> > diff --git a/tools/lib/bpf/libbpf_common.h b/tools/lib/bpf/libbpf_common.h
> > index 947d8bd8a7bb..9ba9f8135dc8 100644
> > --- a/tools/lib/bpf/libbpf_common.h
> > +++ b/tools/lib/bpf/libbpf_common.h
> > @@ -17,6 +17,28 @@
> >
> >  #define LIBBPF_DEPRECATED(msg) __attribute__((deprecated(msg)))
> >
> > +#ifndef LIBBPF_DEPRECATED_SINCE
>
> why #ifndef conditional?

Right, we don't expect to have the macro defined elsewhere. I'll remove
it.

>
> > +#define __LIBBPF_VERSION_CHECK(major, minor) \
> > +       LIBBPF_MAJOR_VERSION > major || \
> > +               (LIBBPF_MAJOR_VERSION == major && LIBBPF_MINOR_VERSION >= minor)
>
> so we don't need this if we do __LIBBPF_CURVER

Right, but we do need to compute an integer for each of the versions
listed below (0.6 for now). I'll see if I can come up with something
short.

>
> > +
> > +/* Add checks for other versions below when planning deprecation of API symbols
> > + * with the LIBBPF_DEPRECATED_SINCE macro.
> > + */
> > +#if __LIBBPF_VERSION_CHECK(0, 6)
> > +#define __LIBBPF_MARK_DEPRECATED_0_6(X) X
> > +#else
> > +#define __LIBBPF_MARK_DEPRECATED_0_6(X)
> > +#endif
> > +
> > +#define __LIBBPF_DEPRECATED_SINCE(major, minor, msg) \
> > +       __LIBBPF_MARK_DEPRECATED_ ## major ## _ ## minor (LIBBPF_DEPRECATED("v" # major "." # minor "+, " msg))
> > +
> > +/* Mark a symbol as deprecated when libbpf version is >= {major}.{minor} */
> > +#define LIBBPF_DEPRECATED_SINCE(major, minor, msg) \
> > +       __LIBBPF_DEPRECATED_SINCE(major, minor, msg)
>
> Is it needed for some macro value concatenation magic to have this
> nested __LIBBPF_DEPRECATED_SINCE?

I double-checked (I needed to, anyway), and it seems not. It's a
leftover from an earlier version of my code, I'll clean it up before
the proper submission.

Thanks!
Quentin

  reply	other threads:[~2021-07-28 21:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 15:38 [PATCH bpf-next v2 0/5] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 1/5] libbpf: rename btf__load() as btf__load_into_kernel() Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 2/5] libbpf: rename btf__get_from_id() as btf__load_from_kernel_by_id() Quentin Monnet
2021-07-23  0:39   ` Andrii Nakryiko
2021-07-23  9:31     ` Quentin Monnet
2021-07-23 15:54       ` Andrii Nakryiko
2021-07-23 16:13         ` Quentin Monnet
2021-07-23 17:18           ` Andrii Nakryiko
2021-07-23 17:44             ` Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 3/5] tools: replace btf__get_from_id() with btf__load_from_kernel_by_id() Quentin Monnet
2021-07-23  0:48   ` Andrii Nakryiko
2021-07-23  9:52     ` Quentin Monnet
2021-07-23 15:57       ` Andrii Nakryiko
2021-07-23 16:17         ` Quentin Monnet
2021-07-21 15:38 ` [PATCH bpf-next v2 4/5] libbpf: add split BTF support for btf__load_from_kernel_by_id() Quentin Monnet
2021-07-23  0:49   ` Andrii Nakryiko
2021-07-21 15:38 ` [PATCH bpf-next v2 5/5] tools: bpftool: support dumping split BTF by id Quentin Monnet
2021-07-23  0:58 ` [PATCH bpf-next v2 0/5] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF Andrii Nakryiko
2021-07-23  2:45   ` Andrii Nakryiko
2021-07-23  9:58     ` Quentin Monnet
2021-07-23 15:51       ` Andrii Nakryiko
2021-07-27 11:39         ` Quentin Monnet
2021-07-27 20:49           ` Andrii Nakryiko
2021-07-28 21:54             ` Quentin Monnet [this message]
2021-07-28 22:29               ` Andrii Nakryiko

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=CACdoK4+HCt6+70rKsWuwqMkuOGGcUPCgretnVp430gb_mWpUQw@mail.gmail.com \
    --to=quentin@isovalent.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    /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.