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

[dthaler1968@googlemail.com]

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.

[...]
> > -``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.

The proposed {} notation matches the C struct initialization convention as a
precedent.

Dave