From: "Mauricio Vásquez Bernal" <mauricio@kinvolk.io>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Rafael David Tinoco <rafaeldtinoco@gmail.com>,
Rafael David Tinoco <rafael.tinoco@aquasec.com>,
Lorenzo Fontana <lorenzo.fontana@elastic.co>
Subject: Re: [PATCH bpf-next 2/2] libbpf: Implement API for generating BTF for ebpf objects
Date: Thu, 28 Oct 2021 17:42:37 -0500 [thread overview]
Message-ID: <CAHap4zt1jFM_hMd0mqT+158f3-C8Vn0AtZHH+pK_MxxiUan5zg@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzYUXYFKyWVbNmfz9Bjui4UytfQs1Qmc24U+bYZwQtRbcw@mail.gmail.com>
> I don't think it's necessary for libbpf to expose all these new APIs.
> The format of CO-RE relocations and .BTF.ext is open and fixed. You
> don't really need to simulate full CO-RE relocation logic to figure
> out which types are necessary. Just go over all .BTF.ext records for
> CO-RE relocations, parse spec (simple format as well) and see which
> fields are accessed.
How do you suggest to match the types for the target BTF without
simulating the CO-RE relocation? Are you suggesting to match them only
by name? We want to generate the minimal BTF that is needed by a given
object. Consider that we could generate these files for thousands of
kernels, size is very important for us. For this reason we chose to
simulate the relocation generating only the types (and members) that
are really needed.
> Either way, this is not libbpf's problem to solve. It's a tooling problem.
I agree. When I started working on this I tried to implement it
without using the libbpf relocation logic, but very soon I realized I
was reimplementing the same logic. Another possibility we have
considered is to expose this relocation logic in the libbpf API,
however I fear it's too complicated and invasive too...
next prev parent reply other threads:[~2021-10-28 22:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 20:37 [PATCH bpf-next 0/2] libbpf: Implement BTF Generator API Mauricio Vásquez
2021-10-27 20:37 ` [PATCH bpf-next 1/2] libbpf: Implement btf__save_to_file() Mauricio Vásquez
2021-10-28 18:36 ` Andrii Nakryiko
2021-10-27 20:37 ` [PATCH bpf-next 2/2] libbpf: Implement API for generating BTF for ebpf objects Mauricio Vásquez
2021-10-28 18:45 ` Andrii Nakryiko
2021-10-28 22:42 ` Mauricio Vásquez Bernal [this message]
2021-10-28 22:48 ` Andrii Nakryiko
2021-10-29 2:33 ` [PATCH bpf-next 0/2] libbpf: Implement BTF Generator API Alexei Starovoitov
2021-10-29 5:41 ` Rafael David Tinoco
2021-10-29 5:51 ` Rafael David Tinoco
2021-10-29 16:12 ` Mauricio Vásquez Bernal
2021-11-02 5:53 ` Andrii Nakryiko
2021-11-02 10:58 ` Leonardo Di Donato
2021-11-02 17:12 ` Andrii Nakryiko
2021-11-02 21:26 ` Mauricio Vásquez Bernal
2021-11-03 5:26 ` Andrii Nakryiko
2021-11-04 14:58 ` Mauricio Vásquez Bernal
2021-11-04 17:34 ` Andrii Nakryiko
2021-11-03 23:40 ` 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=CAHap4zt1jFM_hMd0mqT+158f3-C8Vn0AtZHH+pK_MxxiUan5zg@mail.gmail.com \
--to=mauricio@kinvolk.io \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=lorenzo.fontana@elastic.co \
--cc=netdev@vger.kernel.org \
--cc=rafael.tinoco@aquasec.com \
--cc=rafaeldtinoco@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).