BPF List
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii@kernel.org>,
	bpf@vger.kernel.org, ast@kernel.org,  daniel@iogearbox.net,
	martin.lau@kernel.org
Cc: alan.maguire@oracle.com, jolsa@kernel.org
Subject: Re: [PATCH bpf-next 1/5] libbpf: add BTF field iterator
Date: Tue, 04 Jun 2024 13:37:13 -0700	[thread overview]
Message-ID: <91750196c22c77d28d016ff51ff4bd3452d499e5.camel@gmail.com> (raw)
In-Reply-To: <20240603231720.1893487-2-andrii@kernel.org>

On Mon, 2024-06-03 at 16:17 -0700, Andrii Nakryiko wrote:
> Implement iterator-based type ID and string offset BTF field iterator.
> This is used extensively in BTF-handling code and BPF linker code for
> various sanity checks, rewriting IDs/offsets, etc. Currently this is
> implemented as visitor pattern calling custom callbacks, which makes the
> logic (especially in simple cases) unnecessarily obscure and harder to
> follow.
> 
> Having equivalent functionality using iterator pattern makes for simpler
> to understand and maintain code. As we add more code for BTF processing
> logic in libbpf, it's best to switch to iterator pattern before adding
> more callback-based code.
> 
> The idea for iterator-based implementation is to record offsets of
> necessary fields within fixed btf_type parts (which should be iterated
> just once), and, for kinds that have multiple members (based on vlen
> field), record where in each member necessary fields are located.
> 
> Generic iteration code then just keeps track of last offset that was
> returned and handles N members correctly. Return type is just u32
> pointer, where NULL is returned when all relevant fields were already
> iterated.
> 
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]

> +__u32 *btf_field_iter_next(struct btf_field_iter *it)
> +{
> +	if (!it->p)
> +		return NULL;
> +
> +	if (it->m_idx < 0) {
> +		if (it->off_idx < it->desc.t_cnt)
> +			return it->p + it->desc.t_offs[it->off_idx++];
> +		/* move to per-member iteration */
> +		it->m_idx = 0;
> +		it->p += sizeof(struct btf_type);
> +		it->off_idx = 0;
> +	}
> +
> +	/* if type doesn't have members, stop */
> +	if (it->desc.m_sz == 0) {
> +		it->p = NULL;
> +		return NULL;
> +	}
> +
> +	if (it->off_idx >= it->desc.m_cnt) {
> +		/* exhausted this member's fields, go to the next member */
> +		it->m_idx++;
> +		it->p += it->desc.m_sz;
> +		it->off_idx = 0;
> +	}
> +
> +	if (it->m_idx < it->vlen)
> +		return it->p + it->desc.m_offs[it->off_idx++];

Nit: it is a bit confusing that for two 'if' statements above
     m_idx is guarded by vlen and off_idx is guarded by m_cnt :)

> +
> +	it->p = NULL;
> +	return NULL;
> +}
> +

[...]

  reply	other threads:[~2024-06-04 20:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-03 23:17 [PATCH bpf-next 0/5] libbpf: BTF field iterator Andrii Nakryiko
2024-06-03 23:17 ` [PATCH bpf-next 1/5] libbpf: add " Andrii Nakryiko
2024-06-04 20:37   ` Eduard Zingerman [this message]
2024-06-04 21:40     ` Andrii Nakryiko
2024-06-04 22:08       ` Eduard Zingerman
2024-06-03 23:17 ` [PATCH bpf-next 2/5] libbpf: make use of BTF field iterator in BPF linker code Andrii Nakryiko
2024-06-04 11:02   ` Jiri Olsa
2024-06-04 18:29     ` Andrii Nakryiko
2024-06-03 23:17 ` [PATCH bpf-next 3/5] libbpf: make use of BTF field iterator in BTF handling code Andrii Nakryiko
2024-06-03 23:17 ` [PATCH bpf-next 4/5] bpftool: use BTF field iterator in btfgen Andrii Nakryiko
2024-06-04  0:32   ` Quentin Monnet
2024-06-03 23:17 ` [PATCH bpf-next 5/5] libbpf: remove callback-based type/string BTF field visitor helpers Andrii Nakryiko
2024-06-04 20:56 ` [PATCH bpf-next 0/5] libbpf: BTF field iterator Eduard Zingerman
2024-06-05 10:11   ` Alan Maguire

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=91750196c22c77d28d016ff51ff4bd3452d499e5.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@kernel.org \
    --cc=martin.lau@kernel.org \
    /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