On Fri, May 26, 2023 at 04:02:46PM +0000, Dave Thaler wrote: > 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.) Dave, The following is a quote from version 1.0 of the RISC-V ABI Specification [0]: [0]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0/riscv-abi.pdf > This specification is written in collaboration with the development > communities of the major opensource toolchain and operating system > communities, and as such specifies what has been agreed upon and > implemented. As a result, any changes to this specification that are > not backwards compatible would break ABI compatibility for those > toolchains, which is not permitted unless for features explicitly > marked as experimental, and so will not be made unless absolutely > necessary, regardless of whether the specification is a pre-release > version, ratified version or anything in between. This means any > version of this specification published at the above link can be > regarded as stable in the technical sense of the word (but not > necessarily in the official RISC-V International specification state > meaning), with the official specification state being an indicator of > the completeness, clarity and general editorial quality of the > specification. I'd like to highlight this line in particular: > This means any version of this specification published at the above > link can be regarded as stable in the technical sense of the word (but > not necessarily in the official RISC-V International specification > state meaning), with the official specification state being an > indicator of the completeness, clarity and general editorial quality > of the specification. To my reading, this sounds a lot more like a (strongly advised) informational document, than a formal standard. > 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. Just to make sure we're all on the same page here: Are you proposing that we publish a formal standard for psABI specifications, or are you proposing we publish an informationl document? Thanks, David > > 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 >
