clang generates BPF code with opcode 0x8d (BPF_CALL | BPF_X, which it calls "callx"), when compiling with -O0 or -O1. Of course -O2 is recommended, but if anyone later defines opcode 0x8d for anything other than what clang means by it, it could cause problems. On the BPF_MSH thread at https://mailarchive.ietf.org/arch/msg/bpf/ogmS9qFhdBCxC4VrOWL7nzjSiXU/ Alexei wrote regarding BPF_ABS and BPF_IND: > DW never existed in classic bpf, so abs/ind never had DW flavor. > If some assembler/compiler decided to "support" them it's on them. > The standard must not list such things as deprecated. They never existed. Technically BPF_CALL | BPF_X never existed either, so can be omitted from the IANA registry. But given the widespread deployment of clang's use, and the WG charter statement: > The BPF working group is initially tasked with documenting the existing > state of the BPF ecosystem I could see a potential argument to list it as reserved or something. Today, the document doesn't reserve it, so it's open for future use for any purpose. I just wanted to verify that the WG is ok with not listing it in the IANA registry, given the above information. Dave
