Re: [Bpf] [PATCH v3] bpf, docs: Add additional ABI working draft base text

[Will Hawkins <hawkinsw@obs.cr>]

On Wed, Nov 8, 2023 at 2:51 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Nov 8, 2023 at 2:13 AM Will Hawkins <hawkinsw@obs.cr> wrote:
> >
> > On Tue, Nov 7, 2023 at 8:17 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Tue, Nov 7, 2023 at 11:56 AM Will Hawkins <hawkinsw@obs.cr> wrote:
> > > >
> > > > On Mon, Nov 6, 2023 at 3:38 AM Alexei Starovoitov
> > > > <alexei.starovoitov@gmail.com> wrote:
> > > > >
> > > > > On Sun, Nov 5, 2023 at 4:17 PM Will Hawkins <hawkinsw@obs.cr> wrote:
> > > > > >
> > > > > > On Sun, Nov 5, 2023 at 4:51 AM Alexei Starovoitov
> > > > > > <alexei.starovoitov@gmail.com> wrote:
> > > > > > >
> > > > > > > On Fri, Nov 3, 2023 at 2:20 PM Will Hawkins <hawkinsw@obs.cr> wrote:
> > > > > > > > +
> > > > > > > > +The ABI is specified in two parts: a generic part and a processor-specific part.
> > > > > > > > +A pairing of generic ABI with the processor-specific ABI for a certain
> > > > > > > > +instantiation of a BPF machine represents a complete binary interface for BPF
> > > > > > > > +programs executing on that machine.
> > > > > > > > +
> > > > > > > > +This document is the generic ABI and specifies the parameters and behavior
> > > > > > > > +common to all instantiations of BPF machines. In addition, it defines the
> > > > > > > > +details that must be specified by each processor-specific ABI.
> > > > > > > > +
> > > > > > > > +These psABIs are the second part of the ABI. Each instantiation of a BPF
> > > > > > > > +machine must describe the mechanism through which binary interface
> > > > > > > > +compatibility is maintained with respect to the issues highlighted by this
> > > > > > > > +document. However, the details that must be defined by a psABI are a minimum --
> > > > > > > > +a psABI may specify additional requirements for binary interface compatibility
> > > > > > > > +on a platform.
> > > > > > >
> > > > > > > I don't understand what you are trying to say in the above.
> > > > > > > In my mind there is only one BPF psABI and it doesn't have
> > > > > > > generic and processor parts. There is only one "processor".
> > > > > > > BPF is such a processor.
> > > > > >
> > > > > > What I was trying to say was that the document here describes a
> > > > > > generic ABI. In this document there will be areas that are specific to
> > > > > > different implementations and those would be considered processor
> > > > > > specific. In other words, the ubpf runtime could define those things
> > > > > > differently than the rbpf runtime which, in turn, could define those
> > > > > > things differently than the kernel's implementation.
> > > > >
> > > > > I see what you mean. There is only one BPF psABI. There cannot be two.
> > > > > ubpf can decide not to follow it, but it could only mean that
> > > > > it's non conformant and not compatible.
> > > >
> > > > Okay. That was not how I was structuring the ABI. I thought we had
> > > > decided that, as the document said, an instantiation of a machine had
> > > > to
> > > >
> > > > 1. meet the gABI
> > > > 2. specify its requirements vis a vis the psABI
> > > > 3. (optionally) describe other requirements.
> > > >
> > > > If that is not what we decided then we will have to restructure the document.
> > >
> > > This abi.rst file is the beginning of "BPF psABI" document.
> > > We probably should rename it to psabi.rst to avoid confusion.
> > > See my slides from IETF 118. I hope they explain what "BPF psABI" is for.
> >
> > Of course they do! Thank you! My only question: In the language I was
> > using, I was taking a cue from the System V world where there is a
> > Generic ABI and a psABI. The Generic ABI applies to all System V
> > compatible systems and defines certain processor-specific details that
> > each platform must specify to define a complete ABI. In particular, I
> > took this language as inspiration
> >
> > """
> > The System V ABI is composed of two basic parts: A generic part of the
> > specification describes those parts of the interface that remain
> > constant across all hardware implementations of System V, and a
> > processor-specific part of the specification describes the parts of
> > the specification that are specific to a particular processor
> > architecture. Together, the generic ABI (or gABI) and the processor
> > specific supplement (or psABI) provide a complete interface
> > specification for compiled application programs on systems that share
> > a common hardware architecture.
> > """
>
> I see where you got the inspiration from, but it's not applicable
> in the BPF case. BPF is such one and only processor.
> We're not changing nor adding anything to Sys V generic parts.

That was not quite what I was saying. What I started to draft is
something (yes, modeled after the Sys V (g/ps)ABI) but _brand new_ for
BPF. I think that is where I have been failing to communicate
correctly. What I was proposing was inspired by other ABIs but
completely separate and orthogonal. That is the reason for the
document speaking of a BPF Machine like:

ABI-conforming BPF Machine Instantiation: A physical or logical realization
   of a computer system capable of executing BPF programs consistently with the
   specifications outlined in this document.

because it is a (not necessarily physical) entity that executes BPF
programs (i.e. a "BPF CPU") for which we are specifying the binary
compatibility. In other words, the document as it stands is proposing
a gABI where

the kernel's "BPF CPU" would have its own psABI
ubpf's "BPF CPU" would have its own psABI

and others could do the same into the future so long as they met the
gABI guidelines and properly outlined the way that they handle the
processor-specific details.

My goal with writing was to give us the chance to build a whole
separate structure free and clear from Sys V so we could define our
own rules if/where there is misalignment between BPF programs and
programs that execute on a traditional CPU.

If you believe that we should just define a psABI for BPF and slot in
to the SysV ABI that is perfectly okay with me (again, you are the
expert) but that is very different than the way the currently proposed
document is written.

Will

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf