On Fri, Jul 7, 2023 at 12:01 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Jul 6, 2023 at 6:35 PM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote: > > > > I don't see any problem with defining an IANA registry with multiple "key" fields > > (opcode+src+imm). All existing instructions can be done as such. > > > > Below is strawman text that I think follows IANA's requirements outlined > > in RFC 8126... > > > > -Dave > > > > --- snip --- > > IANA Considerations > > =================== > > > > This document proposes a new IANA registry for BPF instructions, as follows: > > > > * Name of the registry: BPF Instruction Set > > * Name of the registry group: same as registry name > > * Required information for registrations: The values to appear in the entry fields. > > * Syntax of registry entries: Each entry has the following fields: > > * opcode: a 1-byte value in hex format indicating the value of the opcode field > > * src: a 4-bit value in hex format indicating the value of the src field, or "any" > > * imm: either a value in hex format indicating the value of the imm field, or "any" > > * description: description of what the instruction does, typically in pseudocode > > * reference: a reference to the defining specification > > * status: Permanent, Provisional, or Historical > > * Registration policy (see RFC 8126 section 4 for details): > > * Permanent: Standards action > > * Provisional: Specification required > > * Historical: Specification required > > * Initial registrations: See the Appendix. Instructions other than those listed > > as deprecated are Permanent. Any listed as deprecated are Historical. > > I think that might work. What is the next step then? > Who is going to generate such a hex database? I would be more than happy to do that! Will > > -- > Bpf mailing list > Bpf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/bpf
