On Fri, Sep 9, 2022 at 10:31 PM Shmulik Ladkani
<shmulik.ladkani@xxxxxxxxx> wrote:
>
> On Fri, 9 Sep 2022 15:18:57 -0700 Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
>
> > I like the idea, where 'off' is an offset from ptr's offset and 'len'
> > is the number of bytes to trim.
>
> Actually parameters better be 'from' (inclusive) and 'to' (exclusive),
> similar to slicing in most languages. Specifying a negative 'to' provides
> the trimming functionality.
If we do [from, to) then user will have to make sure that they always
provide correct to, which might be quite cumbersome (you'll be calling
bpf_dynptr_get_size() - 1). Ideally this adjustment is optional, so
that user can pass 0, 0 and create exact copy.
So in that regard off_inc and sz_dec (just like I proposed for
internal bpf_dynptr_adjust()) makes most sense, but to be honest it's
quite confusing as they have "opposite directions". So it feels like
just simple bpf_dynptr_clone() followed by bpf_dynptr_{trim/advance}
might be best in terms of principle of least surprise in UAPI design.
>
> > Btw, I will be traveling for the next ~6 weeks and won't have access
> > to a computer, so v2 will be sometime after that.
>
> Enjoy
