On Fri, Mar 01, 2024 at 01:55:34PM -0800, dthaler1968@xxxxxxxxxxxxxx wrote:
> David Vernet <void@xxxxxxxxxxxxx> wrote:
> [...]
> > Very glad that we were able to do this before sending to WG last call.
> Thank
> > you, Dave. I left a couple of comments below but here's my AB:
> >
> > Acked-by: David Vernet <void@xxxxxxxxxxxxx>
> [...]
> > > -``BPF_ADD | BPF_X | BPF_ALU`` means::
> > > +``{ADD, X, ALU}``, where 'code'=``ADD``, 'source'=``X``, and
> 'class'=``ALU``,
> > means::
> >
> > For some reason ``ADD``, ``X`` and ``ALU`` aren't rendering correctly when
> > built with sphinx. It looks like we need to do this:
> [...]
> > -``{ADD, X, ALU}``, where 'code'=``ADD``, 'source'=``X``, and
> 'class'=``ALU``,
> > means::
> > +``{ADD, X, ALU}``, where 'code' = ``ADD``, 'source' = ``X``, and 'class'
> =
> > ``ALU``, means::
>
> Ack. Do you want me to submit a v2 now with that change or hold off for a
> bit? Keep in mind the deadline for submitting a draft before the meeting is
> end-of-day Monday.
I think we can hold off until other people review.
>
> [...]
> > > -``BPF_XOR | BPF_K | BPF_ALU64`` means::
> > > +``{XOR, K, ALU64}`` means::
> >
> > I do certainly personally prefer the notation that was there before, but
> if this
> > more closely matches IETF norms then LGTM.
>
> The notation before assumed the values were full byte values so you could OR
> them together. When they're not full byte values (and they're not in IETF
> convention), OR'ing makes no sense.
Yep
> The proposed {} notation matches the C struct initialization convention as a
> precedent.
Makes sense
Thanks,
David
Attachment:
signature.asc
Description: PGP signature
