On Wed, Oct 21, 2026 at 8:27 AM Leon Hwang <[email protected]> wrote: > > On 2026/10/21 07:25, Andrii Nakryiko wrote: > > On Mon, Oct 19, 2026 at 8:37 AM Leon Hwang <[email protected]> wrote: > > [...] > > >> --- a/tools/lib/bpf/bpf.h > >> +++ b/tools/lib/bpf/bpf.h > >> @@ -484,6 +484,11 @@ LIBBPF_API int bpf_link_create(int prog_fd, int > >> target_fd, > >> enum bpf_attach_type attach_type, > >> const struct bpf_link_create_opts *opts); > >> > >> +LIBBPF_API int bpf_link_create_log(int prog_fd, int target_fd, > >> + enum bpf_attach_type attach_type, > >> + const struct bpf_link_create_opts *opts, > >> + struct bpf_log_opts *log_opts); > > > > Leon, > > > > how about instead of adding this new API, we try to repurpose > > bpf_link_create_opts' iter_info to be used as log opts? we have this > > right now: > > > > union bpf_iter_link_info; /* defined in up-to-date linux/bpf.h */ > > struct bpf_link_create_opts { > > size_t sz; /* size of this struct for forward/backward > > compatibility */ > > __u32 flags; > > union bpf_iter_link_info *iter_info; > > __u32 iter_info_len; > > __u32 target_btf_id; > > union { > > > > > > that iter_info/iter_info_len is a bit of a legacy before we had > > per-attach type union, what if we add iter section into the union, > > wrap iter_info with union and put log_opts there, mark iter_info > > deprecated or something. > > > > I'm not sure anyone is actually using iter_info (I didn't find any > > uses in Meta code base, for instance), but we can detect its use by > > checking iter_info_len: if it's non-zero, then iter_info must be a > > real bpf_iter_link_info. so we should be able to detect this just > > fine, the only downside is that you can't use log_opts and iter_info > > simultaneously, but I think that's fine: you can update your code to > > use new iter.info fields instead, if you need log_opts + iter_info. > > > > WDYT? > > > > IIUC, the struct bpf_link_create_opts will be changed to > > struct bpf_link_create_opts { > size_t sz; /* size of this struct for forward/backward compatibility > */ > __u32 flags; > union { > union bpf_iter_link_info *iter_info; > struct bpf_log_opts *log_opts; > }; > __u32 iter_info_len; > __u32 target_btf_id; > union { > /* ... */ > struct { > union bpf_iter_link_info *info; > __u32 len; > } iter; > }; > }; > > Thereafter, iter.info is preferred against iter_info. And to keep > backward compatibility, iter_info is used only when iter_info_len is > set. But iter_info_len and iter.len are not allowed to be set at the > same time. > > With this change, the bpf_link_create_log API can be dropped. > > I'd like to drop the bpf_link_create_log API first, then add iter.info > in the series of log support for iter link_create in the future.
up to you, but I don't see the problem of dropping bpf_link_create_log API and moving iter.info in the same series > > Thanks, > Leon >
