On Fri, Jul 23, 2021 at 2:58 AM Quentin Monnet [off-list ref] wrote:

2021-07-22 19:45 UTC-0700 ~ Andrii Nakryiko [off-list ref]

quoted

On Thu, Jul 22, 2021 at 5:58 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Wed, Jul 21, 2021 at 8:38 AM Quentin Monnet [off-list ref] wrote:

quoted

As part of the effort to move towards a v1.0 for libbpf [0], this set
improves some confusing function names related to BTF loading from and to
the kernel:

- btf__load() becomes btf__load_into_kernel().
- btf__get_from_id becomes btf__load_from_kernel_by_id().
- A new version btf__load_from_kernel_by_id_split() extends the former to
  add support for split BTF.

The old functions are not removed or marked as deprecated yet, there
should be in a future libbpf version.

Oh, and I was thinking about this whole deprecation having to be done
in two steps. It's super annoying to keep track of that. Ideally, we'd
have some macro that can mark API deprecated "in the future", when
actual libbpf version is >= to defined version. So something like
this:

LIBBPF_DEPRECATED_AFTER(V(0,5), "API that will be marked deprecated in v0.6")

Better:

LIBBPF_DEPRECATED_SINCE(0, 6, "API that will be marked deprecated in v0.6")

I was considering a very advanced feature called “opening a new GitHub

Someone gotta track and ping people at the right time even with
issues, so yeah, it's suboptimal.

issue” to track this :). But the macro game sounds interesting, I'll
look into it for next version.

One nit with LIBBPF_DEPRECATED_SINCE() is that the warning mentions a
version (here v0.6) that we are unsure will exist (say we jump from v0.5
to v1.0). But I don't suppose that's a real issue.

There will always be a +0.1 version just to get deprecation activated.
This is for the reason I explained: we add replacement API in 0.X, but
can mark deprecated API in 0.(X+1), so we won't skip it, even if we
have to wait 2 extra months before 1.0. So I wouldn't worry about
this.

Thanks for the feedback!
Quentin