On Tue, 2025-06-24 at 14:59 -0700, Alexei Starovoitov wrote:
[...]
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 8fd65eb74051..01050d1f7389 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -44,6 +44,11 @@ static const struct bpf_verifier_ops * const bpf_verifier_ops[] = {
> > #undef BPF_LINK_TYPE
> > };
> >
> > +enum bpf_features {
> > + BPF_FEAT_RDONLY_CAST_TO_VOID = 0,
> > + BPF_FEAT_TOTAL,
>
> I don't see the value of 'total', but not strongly against it.
> But pls be consistent with __MAX_BPF_CMD, __MAX_BPF_MAP_TYPE, ...
> Say, __MAX_BPF_FEAT ?
>
>
> Also it's better to introduce this enum in some earlier patch,
> and then always add BTF_FEAT_... to this enum
> in the same patch that adds the feature to make
> sure backports won't screw it up.
> Another rule should be to always assign a number to it.
>
> At the end with random backports the __MAX_BPF_FEAT
> won't be accurate, but whatever.
Ack. Andrii asked to add MAX for people willing to do broken kind of
feature detection and just in case.
