On Thu, Oct 28, 2021 at 3:42 PM Mauricio Vásquez Bernal <mauricio@xxxxxxxxxx> wrote: > > > I don't think it's necessary for libbpf to expose all these new APIs. > > The format of CO-RE relocations and .BTF.ext is open and fixed. You > > don't really need to simulate full CO-RE relocation logic to figure > > out which types are necessary. Just go over all .BTF.ext records for > > CO-RE relocations, parse spec (simple format as well) and see which > > fields are accessed. > > How do you suggest to match the types for the target BTF without > simulating the CO-RE relocation? Are you suggesting to match them only > by name? We want to generate the minimal BTF that is needed by a given > object. Consider that we could generate these files for thousands of > kernels, size is very important for us. For this reason we chose to > simulate the relocation generating only the types (and members) that > are really needed. > How many unnecessary structs are matching if you match by name only? Keep in mind, if your kernel BTF has task_struct and task_struct___2, then CO-RE relocation will keep matching both; and that's not an error for libbpf if all the field offsets will be consistent. In short, I think simple name matching for trimming down BTF is completely adequate. CO-RE relocation has to be more strict about matching, but the subset of types that are used will be the same or almost the same. > > Either way, this is not libbpf's problem to solve. It's a tooling problem. > > I agree. When I started working on this I tried to implement it > without using the libbpf relocation logic, but very soon I realized I > was reimplementing the same logic. Another possibility we have > considered is to expose this relocation logic in the libbpf API, > however I fear it's too complicated and invasive too...
