Re: [Bpf] IETF BPF working group draft charter

[David Vernet <void@manifault.com>]

On Fri, May 26, 2023 at 05:01:57PM +0000, Dave Thaler wrote:
> David Vernet writes:
> [...]
> > 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?
> 
> In an email last week to the list I mentioned Informational as a possibility.
> I don't have a strong preference, but I have a weak preference for Proposed
> Standard status.

Thanks for clarifying. Erik, Suresh and I met yesterday to try and find
a middle ground that addresses everyone's concerns, and we came up with
[0].

[0]: https://github.com/ekline/bpf/blob/ekline-patch-1/charter-ietf-bpf.txt#L31

Does that sound reasonable to you?

I must admit that I feel quite strongly that a Proposed Standard is not
the right move for now. Many of the existing ABI conventions that exist
today are simply artifacts of somewhat arbitrary choices that were made
early-on in libbpf. I say "arbitrary" here not to imply that they
weren't well thought out, but rather just to say that like many other
decisions in software projects, they were made somewhat organically and
without the benefit of hindsight and a larger corpus of participants.

> As an implementer, I would want to make sure that ebpf-for-windows,
> PREVAIL, and uBPF all do the same thing, ideally matching Linux for everything
> the former projects support, to allow using consistent tooling.

I completely understand the motivation. Hopefully an Information
document will address those concerns? Let me know what you think.

- David