All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Marchevsky <davemarchevsky@fb.com>
To: Andrii Nakryiko <andrii@kernel.org>, <bpf@vger.kernel.org>,
	<ast@kernel.org>, <daniel@iogearbox.net>
Cc: <kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 5/9] libbpf: reduce reliance of attach_fns on sec_def internals
Date: Tue, 21 Sep 2021 21:00:29 -0400	[thread overview]
Message-ID: <630a3e62-c91f-d862-684c-619bb703d6d2@fb.com> (raw)
In-Reply-To: <20210920234320.3312820-6-andrii@kernel.org>

On 9/20/21 7:43 PM, Andrii Nakryiko wrote:   
> Move closer to not relying on bpf_sec_def internals that won't be part
> of public API, when pluggable SEC() handlers will be allowed. Drop
> pre-calculated prefix length, and in various helpers don't rely on this
> prefix length availability. Also minimize reliance on knowing
> bpf_sec_def's prefix for few places where section prefix shortcuts are
> supported (e.g., tp vs tracepoint, raw_tp vs raw_tracepoint).
> 
> Given checking some string for having a given string-constant prefix is
> such a common operation and so annoying to be done with pure C code, add
> a small macro helper, str_has_pfx(), and reuse it throughout libbpf.c
> where prefix comparison is performed. With __builtin_constant_p() it's
> possible to have a convenient helper that checks some string for having
> a given prefix, where prefix is either string literal (or compile-time
> known string due to compiler optimization) or just a runtime string
> pointer, which is quite convenient and saves a lot of typing and string
> literal duplication.
> 
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---

Acked-by: Dave Marchevsky <davemarchevsky@fb.com>

>  tools/lib/bpf/libbpf.c          | 41 ++++++++++++++++++---------------
>  tools/lib/bpf/libbpf_internal.h |  7 ++++++
>  2 files changed, 30 insertions(+), 18 deletions(-)
> 

[...]

  reply	other threads:[~2021-09-22  1:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 23:43 [PATCH v2 bpf-next 0/9] libbpf: stricter BPF program section name handling Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 1/9] selftests/bpf: normalize XDP section names in selftests Andrii Nakryiko
2021-09-21  4:55   ` Dave Marchevsky
2021-09-21 23:08     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 2/9] selftests/bpf: normalize SEC("classifier") usage Andrii Nakryiko
2021-09-21  5:20   ` Dave Marchevsky
2021-09-21 23:10     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 3/9] selftests/bpf: normalize all the rest SEC() uses Andrii Nakryiko
2021-09-21  5:41   ` Dave Marchevsky
2021-09-21 23:12     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 4/9] libbpf: refactor internal sec_def handling to enable pluggability Andrii Nakryiko
2021-09-22  0:42   ` Dave Marchevsky
2021-09-22 22:06     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 5/9] libbpf: reduce reliance of attach_fns on sec_def internals Andrii Nakryiko
2021-09-22  1:00   ` Dave Marchevsky [this message]
2021-09-20 23:43 ` [PATCH v2 bpf-next 6/9] libbpf: refactor ELF section handler definitions Andrii Nakryiko
2021-09-22  1:34   ` Dave Marchevsky
2021-09-22 21:54     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 7/9] libbpf: complete SEC() table unification for BPF_APROG_SEC/BPF_EAPROG_SEC Andrii Nakryiko
2021-09-22  1:42   ` Dave Marchevsky
2021-09-22 21:55     ` Andrii Nakryiko
2021-09-22 22:12       ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 8/9] libbpf: add opt-in strict BPF program section name handling logic Andrii Nakryiko
2021-09-22  1:53   ` Dave Marchevsky
2021-09-22 21:57     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 9/9] selftests/bpf: switch sk_lookup selftests to strict SEC("sk_lookup") use Andrii Nakryiko
2021-09-22  2:37   ` Dave Marchevsky

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=630a3e62-c91f-d862-684c-619bb703d6d2@fb.com \
    --to=davemarchevsky@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@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.