Re: [PATCH bpf-next 1/4] libbpf: Add bpf_program__add_flags() and bpf_program__clear_flags()

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 2026-09-10 2:00 a.m., Toke Høiland-Jørgensen wrote:
> Ihor Solodrai <ihor.solodrai@linux.dev> writes:
> 
>> On 9/3/26 2:24 AM, Toke Høiland-Jørgensen wrote:
>>> When changing BPF program flags, applications often need to just add or
>>> remove a single flag. The bpf_program__set_flags() function clobbers any
>>> existing flags value, making this awkward to do non-destructively.
>>
>> I think the whole "non-destructively" language in the series is misleading.
>>
>>      bpf_program__add_flags(prog, BPF_F_XDP_DEV_BOUND_ONLY);
>>
>> does exactly the same thing as
>>
>>      bpf_program__set_flags(prog, bpf_program__flags(prog) | BPF_F_XDP_DEV_BOUND_ONLY);
>>
>> That is: overwriting the prog->prog_flags value. Where is the
>> non-destructiveness?
> 
> bpf_program__add_flags(prog, BPF_F_XDP_DEV_BOUND_ONLY) doesn't overwrite
> any existing flag values, but bpf_program__set_flags(prog,
> BPF_F_XDP_DEV_BOUND_ONLY) does. In your example you handle this in the
> caller, but you have to take pains to do that (which, judging from the
> fixups I had to do earlier, was not something everyone did :)).

Ah, I see. Yeah, __set_flags() may be interpreted as "set *these* flags
that I'm passing in", which is not the way it works here.

Still, I don't like the "destructive" framing of the issue. More like an
API that may be used incorrectly by unfamiliar user.

> 
> However,
> 
>> Let's call this for what it is: a convenience API.
> 
> I don't mind changing the description - will respin with this change.
> Thanks for reviewing!

np, thanks for the patch

> 
> -Toke