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?
