> I'm really lost in this discussion. All aspects of the ABI are > a required part of interoperability. And one of the promises of > this IETF eBPF project is to provide for this interoperability. > > This is a very different situation from the binary ABI for Linux > or Windows, which has traditionally never been interoperable between > vendors, odd examples like iBCS2 [1] notwithstanding. The situation is not that different from the perspective of the producers of the programs. Even within the context of a single system the different vendors of compilers, assemblers, linkers, libc, and other tools need to coordinate and agree on conventions so they all produce compatible programs which are able to interoperate and run on the system. The psABI is what provides for this interoperability, and it works just fine. None of these psABI are maintained as standards in the strong and strict sense (ISO, ANSI, IETF, whatever) and I am just wondering about the convenience of doing so for the BPF ABI, given the nature of these. I reckon the perspective from the system side may be different. No more binary program solipsism :) Example: If I understood correctly from the thread, an IETF standard document is not supposed to be updated regularly. Instead, it is expected to be carefully designed to rely on "codepoints" so all additions are optional and are released in their own document or supplement. As someone who uses ABIs on the toolchain side, and who contributes to some of them, I am personally skeptical that schema can actually accomodate the reality of an alive and evolving ABI, especially one as young as BPF. The resulting "authoritative" documents risk to be outdated more often than not, and end being a curiosity that nobody actually uses. I would be happy to be proved wrong, and of course the WG is free to not share my concerns, but I have to voice them. > I'm fine with watering down the wording in the charter a bit in not > beeing too specific what documebts we want to work on for the binary > compatibility, but I think having it is essential. > > What do we gain by not having the full binary interface in the working > group scope? > > [1] https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard
