Re: [PATCH] libbpf: export inline helpers as symbols for xsk

On Tue, Apr 27, 2021 at 1:20 AM Andrii Nakryiko
[off-list ref] wrote:

On Mon, Apr 26, 2021 at 1:22 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:

quoted

This helps people writing language bindings to not have to rewrite C
wrappers for inline functions in the headers. We force inline the
definition from the header for C and C++ consumers, but also export a
symbol in the library for others. This keeps the performance
advantages similar to using static inline, while also allowing tools
like Rust's bindgen to generate wrappers for the functions.

Also see
https://lore.kernel.org/bpf/CAJ8uoz0QqR97qEYYK=VVCE9A=V=k2tKnH6wNM48jeak2RAmL0A@mail.gmail.com/ (local)
for some context.

Also see https://github.com/xdp-project/xdp-tools/pull/97 for more
discussion on the same.

extern inline is used as it's slightly better since it warns when an
inline definition is missing.

The fvisibility attribute goes on the inline definition, as essentially
it acts as a declaration for the function, while the extern inline
declaration ends up acting as a definition.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---

xsk is moving into libxdp, why not do this there, instead of exporting
a lot of symbols that we'll be deprecating very soon. It will also
incentivise customers to make a move more promptly.

Bjorn, Magnus, what's the status of libxsk in libxdp?

There is a branch in the repo with the xsk support of libbpf
integrated into libxdp. But it has not been merged yet. Toke might
still have some comments on it, do not know, but we have been fixing a
number of issue during the past months (including one in Linux) so it
is stable and performs well now. A simple sample and some tests are
still missing. But the above Rust support is in that branch.

What is your current time plan on the libbpf 1.0 release? Before that
happens, I need to make the Linux samples and selftests self-contained
and not reliant on the xsk support in libbpf since it will be
disappearing. This basically amounts to moving the xsk libbpf
functionality into a separate file and using that from the samples and
tests. At this point in time, relying on the user having libxdp
installed would not be a good idea since if they do not (the majority
of people at this point I believe) it would break the build of
samples/bpf and selftests/bpf. Please let me know what you think?

quoted

 tools/lib/bpf/libbpf.map | 16 ++++++++++++++
 tools/lib/bpf/xsk.c      | 24 +++++++++++++++++++++
 tools/lib/bpf/xsk.h      | 45 +++++++++++++++++++++++-----------------
 3 files changed, 66 insertions(+), 19 deletions(-)

[...]