On Thu, Aug 22, 2024 at 9:55 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Aug 22, 2024 at 9:51 AM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > I don't see why we can't extend the bpf_prog_load() API to allow to > > > > specify those. (would allow to avoid open-coding this whole bpf_attr > > > > business, but it's fine as is as well) > > > > > > Maybe extend API as a followup? > > > The test won't change much, just options instead of bpf_attr. > > > > yep, follow up is good, thanks > > I don't think we want this extension to bpf_prog_load() libbpf api. > This is internal gen_loader use. bpf_prog_load() is just a wrapper around BPF_PROG_LOAD command of bpf() syscall, so it feels appropriate to expose all the available kernel functionality, even if libbpf itself doesn't use some parts of it. Those core_relos fields are there in bpf_attr and are part of UAPI, what's wrong with making them available in low-level API?
