On Tue, Apr 27, 2021 at 1:20 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Mon, Apr 26, 2021 at 1:22 PM Kumar Kartikeya Dwivedi > <memxor@xxxxxxxxx> wrote: > > > > 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@xxxxxxxxxxxxxx/ > > 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@xxxxxxxxx> > > --- > > 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? > > 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(-) > > > > [...]
