| Message ID | 20231103212024.327833-1-hawkinsw@obs.cr (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | BPF |
| Headers | show |
| Series | [v3] bpf, docs: Add additional ABI working draft base text | expand |
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.
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.
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.
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. Will
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.
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. """ See [1]. If you want this document to just be the psABI for Linux, then that is what we will do -- you are the expert and I am just the drafter. [1] https://www.sco.com/developers/gabi/ Will
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.
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
On Wed, Nov 8, 2023 at 3:57 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > 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 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 ?
On Thu, Nov 9, 2023 at 1:31 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Wed, Nov 8, 2023 at 3:57 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > > > 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 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.
On Thu, Nov 9, 2023 at 7:56 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > On Thu, Nov 9, 2023 at 1:31 PM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: > > > > On Wed, Nov 8, 2023 at 3:57 PM Will Hawkins <hawkinsw@obs.cr> wrote: > > > > > > 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 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/
diff --git a/Documentation/bpf/standardization/abi.rst b/Documentation/bpf/standardization/abi.rst index 0c2e10eeb89a..8bb7383688bc 100644 --- a/Documentation/bpf/standardization/abi.rst +++ b/Documentation/bpf/standardization/abi.rst @@ -1,18 +1,159 @@ -.. contents:: -.. sectnum:: - =================================================== BPF ABI Recommended Conventions and Guidelines v1.0 =================================================== -This is version 1.0 of an informational document containing recommended -conventions and guidelines for producing portable BPF program binaries. +An application binary interface (ABI) defines the requirements that one or more +binary software objects must meet in order to guarantee that they can +interoperate and/or use the resources provided by operating systems/hardware +combinations. (For alternate definitions of ABI, see [SYSVABI]_, [POWERPCABI]_) + +The purpose of this document is to define an ABI which will define the extent +to which compiled BPF programs are compatible with each other and the BPF +machine/processor [#]_ on which they are executing. + +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. + +.. contents:: +.. sectnum:: + +How To Use This ABI +=================== + +Conformance +=========== +.. + Red Hat specifies different levels of conformance over time [RHELABI]_. We + could use information from that document here, if we want. + +Related Work +============ +BPF programs are not unique for the way that they operate on a virtualized +machine and processor. There are many programming languages that compile to an +ISA that is specific to a virtual machine. Like the specification presented +herein, those languages and virtual machines also have ABIs. + +For example, the Go programming language and the runtime included statically +with each program compiled from Go source code have a defined ABI [GOABI]_. +Java programs compiled to bytecode follow a well-defined ABI for +interoperability with other compiled Java programs and libraries [JAVAABI]_. +Programs compiled to bytecode for execution as user applications on the Android +operating system (OS) adhere to a bytecode specification that shares much in +common with an ABI [DALVIKABI]_. Finally, the Common Language Runtime (CLR) +designed to execute programs compiled to the Microsoft Intermediate Language +(MSIL) has a fully specified ABI [CLRABI]_. + +Vocabulary +========== + +#. Program: A BPF Program is an ordered set of BPF instructions, with exactly + one entry instruction where the program begins, and one or more exit + instructions where program execution can end. +#. Program Type: Every BPF program has an associated type. The program type + defines, among other things, a program's possible attach types. +#. Attach Type: An attach type defines the set of BPF hook points to which a BPF + program can attach. +#. BPF Hook Points: Places in a BPF-enabled component (e.g., the Linux Kernel, + the Windows kernel) where a BPF program may be attached. +#. 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. +#. ABI-conforming BPF program: A BPF program written to include only the system + routines, commands, and other resources included in this ABI; or a BPF + program compiled into an executable file that has the formats and + characteristics specified for such files in this ABI; or a BPF program whose + behavior complies with the rules given in the ABI [SYSVABI]_. +#. ABI-nonconforming program: A BPF program that is not ABI conforming. +#. Undefined Behavior: Behavior that may vary from instance to instance or may + change at some time in the future. Some undesirable programming practices + are marked in this ABI as yielding undefined behavior [SYSVABI]_. +#. Unspecified Property: A property of an entity defined in this document that + is not explicitly included, defined or referenced in this specification, and + may change at some time in the future. In general, it is not good practice + to make a program depend on an unspecified property [SYSVABI]_. + +Program Execution Environment +============================= + +A loaded BPF program is executed in a freestanding or hosted environment. [#]_. + +BPF Program Freestanding Execution Environment +---------------------------------------------- + +BPF Program Hosted Execution Environment +---------------------------------------- + +A hosted execution environment is one in which a BPF machine instantiation is +embedded within another computer system known as a BPF-enabled application +(e.g., a user application or an operating system kernel). A loaded BPF program +can be attached to a BPF hook point in such a BPF-enabled application +compatible with the attach type of its program type. When the BPF-enabled +application's execution reaches a BPF hook point to which a BPF program is +attached, that BPF program begins execution on the embedded BPF machine at the +program's first instruction. The contents of the embedded BPF machine's +registers and memory at the time it starts execution of the BPF program are +defined by the BPF program's type and attach point. + +Processor Architecture +====================== + +This section describes the processor architecture available +to programs. It also defines the reference language data types, giving the +foundation for system interface specifications [SYSVABI]_ + +Registers +--------- + +General Purpose Registers +^^^^^^^^^^^^^^^^^^^^^^^^^ +BPF has 11 64-bit wide registers, `r0` - `r10`. There exists a single +32-bit wide subregister for each one of the 11 64-bit wide registers. Those +registers do not have their own names -- they are accessible indirectly +through the 32-bit ALU instructions. + +The contents of the registers at the beginning of a BPF program's +execution depend on the program's type. + +Frame Pointer Register +^^^^^^^^^^^^^^^^^^^^^^ +The use of a frame pointer by programs is not required. If, however, a BPF +program does use a frame pointer, it must be stored in register `r10` and +must be read only. + +Data Types +---------- -Registers and calling convention -================================ +Numeric Types +^^^^^^^^^^^^^ -BPF has 10 general purpose registers and a read-only frame pointer register, -all of which are 64-bits wide. +The BPF machine supports 32- and 64-bit signed and unsigned integers. It does +not support floating-point data types. All signed integers are represented in +twos-complement format where the sign bit is stored in the most-significant bit. + +Pointers +^^^^^^^^ + +Function Calling Sequence +========================= +This section defines the standard function calling sequence in a way that +accommodates exceptions, stack management, register (non)volatility, and access +to capabilities of the hosting environment (where applicable). + +Functions in BPF may define between 0 and 5 parameters. Each of the arguments in +a function call are passed in registers. The BPF calling convention is defined as: @@ -23,3 +164,103 @@ The BPF calling convention is defined as: R0 - R5 are scratch registers and BPF programs needs to spill/fill them if necessary across calls. + +Every function invocation proceeds as if it has exclusive access to an +implementation-defined amount of stack space. R10 is a pointer to the byte of +memory with the highest address in that stack space. The contents +of a function invocation's stack space do not persist between invocations. + +.. + Discuss manufactured prologue and epilogue. Take language from the design FAQ. + +Execution Environment Interface +=============================== + +When a BPF program executes in a hosted environment, the hosted environment +may make available to BPF programs certain capabilities. This section +describes those capabilities and the mechanism for accessing them. + + +Program Execution +================= + +Program Return Values +--------------------- + +.. + libbpf currently defines the return value of a bpf program as a 32-bit unsigned + integer. ubpf currently defines the return value of a bpf program. + +Program Loading and Dynamic Linking +----------------------------------- +This section describes the object file information and system actions that +create running programs. Some information here applies to all systems; +information specific to one processor resides in sections marked accordingly +[SYSVABI]_. + +BPF programs saved in ELF files must be loaded from storage and properly +configured before they can be executed on a BPF machine. + +Program Loading (Processor-Specific) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Dynamic Linking +^^^^^^^^^^^^^^^ + +Global Offset Table (Processor-Specific) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Procedure Linkage Table (Processor-Specific) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Exception Handling +================== + +BPF Program Types +================== +.. This information may end up as a subsection somewhere else. + +BPF Maps +========= +.. This information may end up as a subsection somewhere else. + +System Calls +============ + +**TODO** + +C Programming Language Support +============================== + +.. + This section could be included in order to define the contents of standardized + processor-specific header files that would make it easier for programmers to + write programs. + +Notes +===== +.. [#] The BPF machine does not need to be a physical instantiation of a processor. + In fact, many instantiations of BPF machines are virtual. +.. [#] See the [CSTD]_ for the inspiration for this distinction. + +References +========== + +.. [SYSVABI] System V Application Binary Interface - Edition 4.1. SCO Developer Specs. + The Santa Cruz Operation. 1997. + https://www.sco.com/developers/devspecs/gabi41.pdf. +.. [POWERPCABI] Developing PowerPC Embedded Application Binary Interface (EABI) + Compliant Programs. PowerPC Embedded Processors Application Note. IBM. 1998. + http://class.ece.iastate.edu/arun/Cpre381_Sp06/lab/labw12a/eabi_app.pdf. +.. [GOABI] Go internal ABI specification. Go Source Code. No authors. 2023. + https://go.googlesource.com/go/+/refs/heads/master/src/cmd/compile/abi-internal.md. +.. [JAVAABI] The Java (r) Language Specification - Java SE 21 Edition. Gosling, James et. al. + Oracle. 2023. https://docs.oracle.com/javase/specs/jls/se21/html/index.html. +.. [DALVIKABI] Dalvik Bytecode. Android Core Runtime Documentation. No authors. Google. + 2022. https://source.android.com/docs/core/runtime/dalvik-bytecode. +.. [CLRABI] CLR ABI. The Book of the Runtime. No authors. Microsoft. 2023. + https://github.com/dotnet/coreclr/blob/master/Documentation/botr/clr-abi.md. +.. [CSTD] International Standard: Programming Languages - C. ISO/IEC. 2018. + https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf. +.. [RHELABI] Red Hat Enterprise Linux 8: Application Compatibility Guide. Red Hat. + 2023. https://access.redhat.com/articles/rhel8-abi-compatibility.
Per David's description of the IETF standardization process, this document will form the basis for an informational eBPF ABI. The work in this commit is a slightly more complete skeleton for the work that we will do. Everything in this document (from formatting to topics to details) is open for change and feedback. --- Documentation/bpf/standardization/abi.rst | 259 +++++++++++++++++++++- 1 file changed, 250 insertions(+), 9 deletions(-) Changelog: v1 -> v2: - Address David's comments - Reflow to a max of 80 character lines (Christoph's feedback) v2 -> v3: - Update Java Language Specification reference to version 21 - Make author's notes into comments. - Fix minor typographical errors in References section.