Re: [PATCH v9 bpf-next 04/10] libbpf: Add layout encoding support
Alan Maguire <[email protected]>
| Newsgroups | org.kernel.vger.dwarves,org.kernel.vger.bpf |
|---|---|
| Message-ID | <[email protected]> |
On 26/02/2026 10:05, [email protected] wrote: >> Layout information is maintained in btf.c in the layouts[] array; >> when BTF is created with the add_layout option in represents the >> current view of supported BTF kinds. > > There is a typo in the commit message: "in represents" should be > "it represents". > >> diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h >> index b30008c267c0..a1f8deca2603 100644 >> --- a/tools/lib/bpf/btf.h >> +++ b/tools/lib/bpf/btf.h > > [ ... ] > >> +struct btf_new_opts { >> + size_t sz; >> + struct btf *base_btf; /* optional base BTF */ >> + bool add_layout; /* add BTF layout information */ >> + size_t:0; >> +}; > > In v8, Andrii Nakryiko asked why this is an option rather than > always emitting layout unconditionally: > > https://lore.kernel.org/bpf/CAEf4BzZuFB6zvMjdqKDumUAT4vr5MeA3LBqTh5xRZmAQ5KC10g@mail.gmail.com/ > > Was there a reason the suggestion to always emit layout and > sanitize it for older kernels was not followed? > There was a reason; how would this sanitization happen for kernel BTF? Program BTF can be sanitized in userspace prior to loading, but kernel BTF cannot unless we stable-backported a kernel change that could handle presence of kind layout. That was rejected as an approach last time, so I can't see a way to do this. So given that pahole can be used on older kernels to generate their BTF, we need to use an option here as we do for many other BTF features like enum64, variables etc. > > --- > AI reviewed your patch. Please fix the bug or email reply why it's not a bug. > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md > > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22436234361 > > AI-authorship-score: low > AI-authorship-explanation: Long lore history (v3-v9 spanning 2023-2026), iterative reviewer feedback, human-style typo in commit message, and consistent with author's established BPF contributions. > issues-found: 2 > issue-severity-score: low > issue-severity-explanation: A commit message typo and an unaddressed maintainer design request about always emitting layout rather than making it optional; no functional bugs found.