On 30-Aug 19:24, Song Liu wrote: > > > > On Aug 30, 2019, at 11:53 AM, Anton Protopopov <[email protected]> > > wrote: > > > > чт, 29 авг. 2019 г. в 16:02, Song Liu <[email protected]>: > >> > >> > >> > >>> On Aug 14, 2019, at 5:03 PM, Anton Protopopov <[email protected]> > >>> wrote: > >>> > >> > >> [...] > >> > >>> > >>> > >>> int bpf_object__unload(struct bpf_object *obj) > >>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > >>> index e8f70977d137..634f278578dd 100644 > >>> --- a/tools/lib/bpf/libbpf.h > >>> +++ b/tools/lib/bpf/libbpf.h > >>> @@ -63,8 +63,13 @@ LIBBPF_API libbpf_print_fn_t > >>> libbpf_set_print(libbpf_print_fn_t fn); > >>> struct bpf_object; > >>> > >>> struct bpf_object_open_attr { > >>> - const char *file; > >>> + union { > >>> + const char *file; > >>> + const char *obj_name; > >>> + }; > >>> enum bpf_prog_type prog_type; > >>> + void *obj_buf; > >>> + size_t obj_buf_sz; > >>> }; > >> > >> I think this would break dynamically linked libbpf. No? > > > > Ah, yes, sure. What is the right way to make changes which break ABI in > > libbpf? > > I don't have a good idea here on the top of my head. > > Maybe we need a new struct and/or function for this.
I incorporated the suggested fixes and sent a new patch for this as we ran into pretty much the same issue. (i.e. not being able to set needs_kver / flags). https://lore.kernel.org/bpf/[email protected]/T/#u - KP > > > > > BTW, does the commit ddc7c3042614 ("libbpf: implement BPF CO-RE offset > > relocation algorithm") which adds a new field to the struct > > bpf_object_load_attr also break ABI? > > I think this change was in the same release, so it is OK. > > Thanks, > Song
