On Thu, Nov 9, 2023 at 7:56 PM Will Hawkins <hawkinsw@xxxxxx> wrote: > > On Thu, Nov 9, 2023 at 1:31 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Wed, Nov 8, 2023 at 3:57 PM Will Hawkins <hawkinsw@xxxxxx> wrote: > > > > > > On Wed, Nov 8, 2023 at 2:51 PM Alexei Starovoitov > > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > > > On Wed, Nov 8, 2023 at 2:13 AM Will Hawkins <hawkinsw@xxxxxx> wrote: > > > > > > > > > > On Tue, Nov 7, 2023 at 8:17 PM Alexei Starovoitov > > > > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > > > > > > > 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. > > > > > > > > > > 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 how would you expect that to work? > > psABI is a compiler spec in the first place. > > The user would use clang -O2 -target bpf_kernel vs -target bpf_ubpf ? > > They could use some other compiler, too. I hit send too soon. Sorry. To elaborate, it is my opinion that a (g/ps)ABI does more than just specify a compiler. There are also aspects that have an impact on the linker and the loader, among others. See, e.g., Chapter 3 Section 4 of the x86-64 psABI describing process initialization. Or, 3.7 of the same document describing a stack unwinding algorithm. I think that we should write our documents with the *expectation* that an ecosystem of tools will exist beyond the ones that exist now. That way we won't end up in the "Perl is the only thing that can parse Perl" conundrum. What's more, clang is even today not the only thing that generates BPF machine code ([1], among others, I'm sure!). [1] https://github.com/Alan-Jowett/bpf_conformance/
