Re: [Bpf] [PATCH bpf-next] bpf, docs: Use IETF format for field definitions in instruction-set.rst

[David Vernet <void@manifault.com>]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

On Fri, Mar 01, 2024 at 01:55:34PM -0800, dthaler1968@googlemail.com wrote:
> David Vernet <void@manifault.com> 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@manifault.com>
> [...]
> > > -``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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]