Re: [PATCH bpf-next v2 5/6] libbpf: Add bpf_link_create_log API

[Leon Hwang]

On 2026/10/21 07:25, Andrii Nakryiko wrote:
> On Mon, Oct 19, 2026 at 8:37 AM Leon Hwang <leon.hw...@linux.dev> 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.

Thanks,
Leon