> Tracing progs will be peeking into task_struct. > To describe it in the reduced BTF most of the kernel types would be needed, That's the point of our algorithm. If a program is only accessing 'pid' on 'task_struct' we'll generate a BTF representation of task_struct that only contains the 'pid' member with the right offset, other members are not included and hence we don't need to carry on all those types that are not used by the program. > Have you considered generating kernel BTF with fields that are accessed > by bpf prog only and replacing all other fields with padding ? Yeah. We're implicitly doing it as described above. > I think the algo would be quite different from the actual CO-RE logic > you're trying to reuse. I'm not 100% sure it's so easy to do without reimplementing much of the actual CO-RE logic. We don't want to copy all type members but only the ones actually used. So I'm not sure if Andrii's idea of performing the matching based only on the type name will work. I'll try to get deep into the details and will be back to you soon. > If CO-RE matching style is necessary and it's the best approach then please > add new logic to bpftool. I'm not sure such api would be > useful beyond this particular case to expose as stable libbpf api. I agree 100%. Our goal is to have this available on bpftool so all the community can use it. However it'd be a shame if we can't use some of the existing logic in libbpf.
