On Thu, Oct 5, 2023 at 1:14 PM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote: > > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Sep 29, 2023 at 1:17 PM Dave Thaler > > <dthaler=40microsoft.com@xxxxxxxxxxxxxx> wrote: > > > Now that we have some new "v4" instructions, it seems a good time to > > > ask about what it means to support (or comply with) the ISA RFC once > > > published. Does it mean that a verifier/disassembler/JIT compiler/etc. MUST > > support *all* the > > > non-deprecated instructions in the document? That is any runtime or tool that > > > doesn't support the new instructions is considered non-compliant with the BPF > > ISA? > [...] > > > Or should we create some things that are SHOULDs, or finer grained > > > units of compliance so as to not declare existing deployments non-compliant? > > > > I suspect 'non-compliance' label will cause an unnecessary backlash, so I would > > go with SHOULD wording. > > Yeah, but if each instruction is a separate SHOULD, then a runtime could (say) > support one atomic instruction and not others. Having that level of granularity > would really complicate interoperability and cross-platform tooling in my opinion. > So it might be better to list groups of instructions and have the SHOULD be at the > granularity of a group? I guess we can group them based on LLVM evolution of the instruction set: -mcpu=v1,v2,v3,v4 but it would have mainly historical benefits and not practical. Grouping atomic vs not is not realistic either, since atomic_xadd was there since the very beginning. I suspect any kind of grouping scheme will end up in bike shedding. My preference would be to agree on either SHOULD or MUST for all insns currently described in ISA doc. We can go with MUST to force compliance. Some archs, OSes, JITs won't be compliant in the short term, but MUST wording will be a good motivation to do the work now instead of later.
