Jose E. Marchesi wrote: > > 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. The RISC-V calling convention is indeed maintained as a standard. https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf is the relevant document by RISC-V International which per https://riscv.org/about/ is a standards organization. (I haven't participated in it, via the Confidential Computing Consortium I have interacted with some people who have.) The eBPF Foundation could publish the equivalent of the riscv-calling.pdf document above, but we (the IETF and BPF communities) decided the IETF was the best place to publish such documents. As such, I envision an IETF RFC for the BPF calling convention that is very similar to the RISC-V standard one above. Given the precedent, and the need in BPF, I don't see a problem. > 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. See the RISC-V document above. Dave
