Re: [PATCH v8 bpf-next 03/10] libbpf: use kind layout to compute an unknown kind size

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2025-12-16 at 14:23 -0800, Andrii Nakryiko wrote:

[...]

> Ok, so what you are saying is that if there is layout info we should
> always use that instead of hard-coded knowledge about kind layout,
> right? Ok, I can agree to that, but see note about extensibility
> below.
>
> But that's a bit different from validating that the recorded layout
> of, say, BTF_KIND_STRUCT is what we expect (sizeof(struct btf_type) +
> vlen * sizeof(struct btf_member)). Because if we enforce that, then we
> still preclude any extensions to those layouts in the future. And if
> we do that, what's the point of looking at layout info for kinds we do
> know about?

If full flexibility is allowed, then all places where e.g. libbpf
iterates params or struct members require an update. That's a big
change.

I suggested checking layout sizes for existing types as a half-measure
allowing to avoid such changes.

> > Given that BTF rewrites would only be unsound in presence of unknown
> > types the whole feature looks questionable to me.
> 
> What are those "BTF rewrites" you are referring to? I'm getting a bit
> lost in this discussion, tbh.

E.g. btf__permute(), as it will not permute all types if some of the
are unknown. Or dedup.

> This feature is designed to allow introducing new (presumably,
> optional) kinds and not break older versions of libbpf/bpftool to at
> least be able to dump known contents. Does the current implementation
> achieve that goal? What other goals do you think this feature should
> support?

I don't think anything other than dump is possible to support.

[...]