Re: [Bpf] IETF BPF working group draft charter

["Jose E. Marchesi" <[e-mail]>]

> 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