On Tue, Nov 7, 2023 at 11:56 AM Will Hawkins <hawkinsw@xxxxxx> wrote: > > On Mon, Nov 6, 2023 at 3:38 AM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Sun, Nov 5, 2023 at 4:17 PM Will Hawkins <hawkinsw@xxxxxx> wrote: > > > > > > On Sun, Nov 5, 2023 at 4:51 AM Alexei Starovoitov > > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > > > On Fri, Nov 3, 2023 at 2:20 PM Will Hawkins <hawkinsw@xxxxxx> 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.
