Re: [Bpf] Standardizing BPF assembly language?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 23, 2024 at 8:46 AM
<dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> wrote:
>
> At LSF/MM/BPF 2023, Jose gave a presentation about BPF assembly
> language (http://vger.kernel.org/bpfconf2023_material/compiled_bpf.txt).
>
> Jose wrote in that link:
> > There are two dialects of BPF assembler in use today:
> >
> > - A "pseudo-c" dialect (originally "BPF verifier format")
> >  : r1 = *(u64 *)(r2 + 0x00f0)
> >  : if r1 > 2 goto label
> >  : lock *(u32 *)(r2 + 10) += r3
> >
> > - An "assembler-like" dialect
> >  : ldxdw %r1, [%r2 + 0x00f0]
> >  : jgt %r1, 2, label
> >  : xaddw [%r2 + 2], r3
>
> During Jose's talk, I discovered that uBPF didn't quote match the second
> dialect
> and submitted a bug report.  By the time the conference was over, uBPF had
> been updated to match GCC, so that discussion worked to reduce the number of
> variants.
>
> As more instructions get added and supported by more tools and compilers
> there's the risk of even more variants unless it's standardized.
>
> Hence I'd recommend that BPF assembly language get documented in some WG
> draft.  If folks agree with that premise, the first question is then: which
> document?
> One possible answer would be the ISA document that specifies the
> instructions,
> since that would the IANA registry could list the assembly for each
> instruction,
> and any future documents that add instructions would necessarily need to
> specify
> the assembly for them, preventing variants from springing up for new
> instructions.
>
> A second question would be, which dialect(s) to standardize.  Jose's link
> above
> argues that the second dialect should be the one standardized (tools are
> free to
> support multiple dialects for backwards compat if they want).  See the link
> for
> rationale.
>
> Thoughts?

Someone from Bell will go off and invent their own variation no matter
what we do. Snark aside I think it's useful for documents to be able
to contain excepts of code without needing to expect readers to decode
BPF from hex in their heads, and we should write down that format
somewhere.

Sincerely,
Watson


--
Astra mortemque praestare gradatim





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux