Re: [Bpf] IETF BPF working group draft charter

[David Vernet <void@manifault.com>]

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
>