On Thu, Aug 22, 2024 at 10:27 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > 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? because it's a maintenance cost for something where the single user is a selftest. Hence I wouldn't bother, but I don't insist.
