On Tue, Jan 24, 2023 at 9:17 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Wed, Jan 18, 2023 at 8:32 PM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Wed, Jan 18, 2023 at 11:48:59AM +0100, Daniel Borkmann wrote:
> > >
> > > My $0.02 is that I don't think we need to make a hard-cut ban as part of this.
> >
> > The hard-cut is easier to enforce otherwise every developer will be arguing that
> > their new feature is special and it requires a new discussion.
> > This thread has been going for too long. We need to finish it now and
> > don't come back to it again every now and then.
>
> I wish that we could grant exception at least to complete dynptr
> basics (bpf_dynptr_is_null, bpf_dynptr_get_size,
> bpf_dynptr_{clone,trim,advance}) so that it is consistently provided
> as a unified set of helpers. Similarly, for open coded loop iterator
> (3 helpers), I believe it would be better for BPF ecosystem overall to
> work on any BPF-enabled architecture and configuration (no matter JIT
> or not, BTF of not, etc), just due to generality and unassuming nature
> of this functionality.
>
> But it is what it is, let's move on.
Just to expand a bit on the above and make it clearer. I don't like a
hard-cut ban on helpers, but I'll disagree and commit and will move
open-coded iterators to kfuncs. And whoever is waiting on the helpers
vs kfuncs decision should stop waiting and use kfuncs.
[...]
