All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hengqi Chen <hengqi.chen@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>, Yonghong Song <yhs@fb.com>,
	john fastabend <john.fastabend@gmail.com>
Subject: Re: [PATCH bpf-next] libbpf: add libbpf_load_vmlinux_btf/libbpf_load_module_btf APIs
Date: Tue, 27 Jul 2021 09:12:38 +0800	[thread overview]
Message-ID: <db11440c-c9ce-9007-9a03-7395d6facfe7@gmail.com> (raw)
In-Reply-To: <CAEf4BzaZEny+3iu6ZGqAaY8QGE27TJoky=pzMcyg934_cJ3QTg@mail.gmail.com>



On 7/27/21 6:49 AM, Andrii Nakryiko wrote:
> On Fri, Jul 23, 2021 at 10:13 PM Hengqi Chen <hengqi.chen@gmail.com> wrote:
>>
>> Add libbpf_load_vmlinux_btf/libbpf_load_module_btf APIs.
>> This is part of the libbpf v1.0. [1]
>>
>> [1] https://github.com/libbpf/libbpf/issues/280
> 
> Saying it's part of libbpf 1.0 effort and given a link to Github PR is
> not really a sufficient commit message. Please expand on what you are
> doing in the patch and why.
> 

Will do.

>>
>> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
>> ---
>>  tools/lib/bpf/btf.c      | 24 +++++++++++++++++++++++-
>>  tools/lib/bpf/btf.h      |  2 ++
>>  tools/lib/bpf/libbpf.c   |  8 ++++----
>>  tools/lib/bpf/libbpf.map |  2 ++
>>  4 files changed, 31 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>> index b46760b93bb4..414e1c5635ef 100644
>> --- a/tools/lib/bpf/btf.c
>> +++ b/tools/lib/bpf/btf.c
>> @@ -4021,7 +4021,7 @@ static void btf_dedup_merge_hypot_map(struct btf_dedup *d)
>>                  */
>>                 if (d->hypot_adjust_canon)
>>                         continue;
>> -
>> +
>>                 if (t_kind == BTF_KIND_FWD && c_kind != BTF_KIND_FWD)
>>                         d->map[t_id] = c_id;
>>
>> @@ -4395,6 +4395,11 @@ static int btf_dedup_remap_types(struct btf_dedup *d)
>>   * data out of it to use for target BTF.
>>   */
>>  struct btf *libbpf_find_kernel_btf(void)
>> +{
>> +       return libbpf_load_vmlinux_btf();
>> +}
>> +
>> +struct btf *libbpf_load_vmlinux_btf(void)
>>  {
>>         struct {
>>                 const char *path_fmt;
>> @@ -4440,6 +4445,23 @@ struct btf *libbpf_find_kernel_btf(void)
>>         return libbpf_err_ptr(-ESRCH);
>>  }
>>
>> +struct btf *libbpf_load_module_btf(const char *mod)
> 
> So we probably need to allow user to pre-load and re-use vmlinux BTF
> for efficiency, especially if they have some use-case to load a lot of
> BTFs.
> 

Should the API change to this ?

struct btf *libbpf_load_module_btf(struct btf *base, const char *mod)

It seems better for the use-case you mentioned.

>> +{
>> +       char path[80];
>> +       struct btf *base;
>> +       int err;
>> +
>> +       base = libbpf_load_vmlinux_btf();
>> +       err = libbpf_get_error(base);
>> +       if (err) {
>> +               pr_warn("Error loading vmlinux BTF: %d\n", err);
>> +               return base;
> 
> libbpf_err_ptr() needs to be used here, pr_warn() could have destroyed
> errno already
> 

OK.

>> +       }
>> +
>> +       snprintf(path, sizeof(path), "/sys/kernel/btf/%s", mod);
>> +       return btf__parse_split(path, base);
> 
> so who's freeing base BTF in this case?
> 

Sorry, missed that.
But if we change the signature, then leave this to user.

>> +}
>> +
>>  int btf_type_visit_type_ids(struct btf_type *t, type_id_visit_fn visit, void *ctx)
>>  {
>>         int i, n, err;
> 
> [...]
> 

  reply	other threads:[~2021-07-27  1:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-24  5:12 [PATCH bpf-next] libbpf: add libbpf_load_vmlinux_btf/libbpf_load_module_btf APIs Hengqi Chen
2021-07-26 22:49 ` Andrii Nakryiko
2021-07-27  1:12   ` Hengqi Chen [this message]
2021-07-27 18:18     ` 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=db11440c-c9ce-9007-9a03-7395d6facfe7@gmail.com \
    --to=hengqi.chen@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=yhs@fb.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 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.