* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-17 18:19 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-17 18:19 UTC (permalink / raw)
To: Jose E. Marchesi, Dave Thaler; +Cc: bpf@ietf.org, bpf
Jose E. Marchesi wrote:
> As I mentioned during your talk at LSF/MM/BPF, I think that two items may be
> a bit confusing, and worth to clarify:
>
> * the eBPF bindings for the ELF executable file format,
>
> What does "eBPF bindings" mean in this context? I think there are at least two
> possible interpretations:
>
> 1) The way BPF uses ELF, not impacting internal ELF structures. For
> example the special section names that a conformant BPF loader
> expects and understands, such as ".probes", or rules on how to use
> the symbols visibility, or how notes are used (if they are used) etc
>
> 2) The ELF extensions that BPF introduces (and may introduce at some
> point) as an architecture, such as machine number, section types,
> special section indices, segment types, relocation types, symbol
> types, symbol bindings, additional section and segment flags, file
> flags, and perhaps structures of the contents of some special
> sections.
See https://www.ietf.org/archive/id/draft-thaler-bpf-elf-00.html
It includes the values used in the ELF header, section naming,
use of the "license" and "version" sections, meaning of "maps" and
".maps" sections, etc.
> If the intended meaning of that point in the draft is 1), then I would suggest to
> change the wording to something like:
>
> * the requirements and expectations that ELF files shall fulfill so they
> can be handled by conformant eBPF implementations.
My own opinion is to leave the more detailed definition of what belongs
in the ELF spec vs another document up to the WG to define rather than
baking it into the charter.
> Otherwise, if the intended meaning in the draft charter is to cover 2), I would
> like to note that, usually and conventionally ELF extensions introduced by
> architectures (and operating systems in the ELF sense)
> are:
>
> - Part of the psABI (chapter Object Files).
>
> - Not standards, in the sense that these are not handled by
> standardization bodies.
>
> - Maintained by corporations, associations, and/or community groups, and
> published in one form or another. A few examples of both arch and os
> extensions:
>
> + The x86_64 psABI, including the ELF bits, is maintained by Intel
> (mainly by HJ Lu, a toolchain hacker) and available in a git repo in
> gitlab [1].
>
> + The risc-v psABI, including the ELF bits, is maintained by I believe
> RISC-V International and the community, and is available in a git
> repo in github [2].
>
> + The GNU extensions to the gABI, including the ELF bits, is
> maintained by GNU hackers and available in a git repo in sourceware
> [3].
>
> + The llvm extensions to ELF, which in this case take the form of an
> "os" in the ELF sense even if it is not an operating system, are
> maintained by the LLVM project and available in the
> docs/Extensions.rst file in the llvm source distribution.
>
> Note that more often than not this is kept quite informally, without
> the need of much bureocratic overhead. A git repo in github or the
> like, maintained by the eBPF foundation or similar, would be more than
> enough IMO.
To ensure interoperability, I'd want a slightly more formal specification.
> - Open to suggestions and contributions from the community, vendors,
> implementors, etc. This usually involves having a mailing list where
> such suggestions can be sent an discussed. Almost always very little
> discussion is required, if any, because the proposed extension has
> already been agreed and worked on by the involved parties: toolchains,
> consumers, etc.
>
> - Continuously evolving.
>
> So, would the IETF working group be able to accomodate something like the
> above? For example, once a document is officially published by the working
> group, how easy is it to modify it and make a new version to incorporate
> something new, like a new relocation type for example?
> (Apologies for my total ignorance of IETF business :/)
There's 3 ways:
1) The IETF can publish an extension spec with additional optional features.
2) The IETF can publish a replacement to the original (not usually desirable)
3) The IETF can define a process for other organizations or vendors to create
their own extensions, and some mechanism for ensuring that two such
extensions don't collide using the same codepoint. This is what the charter
implies the WG should do.
Dave
> Likewise, of the following item:
>
> * the platform support ABI, including calling convention, linker
> requirements, and relocations,
>
> The calling convention and relocations are part of the psABI and usually
> handled like described above.
>
> PS: BPF is obviously not a SysV system, but when it comes to document
> the ABI, including the ELF bits, I think it would be a good idea to
> use the same document structure conventionally used by psABI, as
> Alexei already suggested some time ago. This would be most familiar
> to people.
>
> [1]
> https://gitlab/.
> com%2Fx86-psABIs%2Fx86-64-
> ABI&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f514d
> 08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6381
> 99331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sd
> ata=SaprU2J9WsyJ5qhcxIGKO2F06YtO%2Bm1Gpjb2SIOApLA%3D&reserved=0
> [2]
> https://github/
> .com%2Friscv-non-isa%2Friscv-elf-psabi-
> doc%2Freleases%2Fdownload%2Fv1.0%2Friscv-
> abi.pdf&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f5
> 14d08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> 38199331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C
> &sdata=uKqnU93kcu8rZ9Y0gzWdmuHnK9ySPM847%2FDMm6vJNwQ%3D&res
> erved=0
> [3] git://sourceware.org/git/gnu-gabi.git
>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.i/
> etf.org%2Fmailman%2Flistinfo%2Fbpf&data=05%7C01%7Cdthaler%40microso
> ft.com%7Cd4f2ef78d9e0475f514d08db56e91312%7C72f988bf86f141af91ab2
> d7cd011db47%7C1%7C0%7C638199331900533629%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C2000%7C%7C%7C&sdata=W9FXcUwb181VQ6ksF2guASQ5FGtTE
> KZuE0Yb8cHR9vI%3D&reserved=0
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-17 21:00 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-17 21:00 UTC (permalink / raw)
To: Dave Thaler; +Cc: Jose E. Marchesi, Dave Thaler, bpf@ietf.org, bpf
On Wed, May 17, 2023 at 06:19:42PM +0000, Dave Thaler wrote:
> Jose E. Marchesi wrote:
> > As I mentioned during your talk at LSF/MM/BPF, I think that two items may be
> > a bit confusing, and worth to clarify:
> >
> > * the eBPF bindings for the ELF executable file format,
> >
> > What does "eBPF bindings" mean in this context? I think there are at least two
> > possible interpretations:
> >
> > 1) The way BPF uses ELF, not impacting internal ELF structures. For
> > example the special section names that a conformant BPF loader
> > expects and understands, such as ".probes", or rules on how to use
> > the symbols visibility, or how notes are used (if they are used) etc
> >
> > 2) The ELF extensions that BPF introduces (and may introduce at some
> > point) as an architecture, such as machine number, section types,
> > special section indices, segment types, relocation types, symbol
> > types, symbol bindings, additional section and segment flags, file
> > flags, and perhaps structures of the contents of some special
> > sections.
>
> See https://www.ietf.org/archive/id/draft-thaler-bpf-elf-00.html
> It includes the values used in the ELF header, section naming,
> use of the "license" and "version" sections, meaning of "maps" and
> ".maps" sections, etc.
I have what may be a silly question: The document you linked specifies,
"This specification is a [sic] extension to the ELF file format as
specified in Chapter 4 of the System V Application Binary Interface
[ELF]."
What does it mean exactly for an IETF-published BPF ELF extension to be
an extension of a specification from a totally separate standards body
(in this case, the System V release 4 ABI / Tool Interface Standard
(TIS))? In other words, is it normal for extensions to be specified in
external / separate standards bodies from where the original
specification is defined? It seems like that could potentially result in
a confusing outcome if the original standards body could itself
eventually choose to publish its own extension which conflicts with the
IETF. That won't happen for Sys V of course, but in general it seems odd
for us to publish an extension for a specification that was defined in
the System V ABI instead of the IETF, and it seems like a situation for
which following the existing contours for x86_64, ARM, etc might make
sense.
> > If the intended meaning of that point in the draft is 1), then I would suggest to
> > change the wording to something like:
> >
> > * the requirements and expectations that ELF files shall fulfill so they
> > can be handled by conformant eBPF implementations.
>
> My own opinion is to leave the more detailed definition of what belongs
> in the ELF spec vs another document up to the WG to define rather than
> baking it into the charter.
I tend to agree, but that seems to suggest that we should remove this
line from the charter, and instead leave it up to the WG to determine if
it should be included:
* the eBPF bindings for the ELF executable file format,
Or is your point rather that the line in the charter as it exists now is
really saying that discussing ELF *in general* is in scope for the
working group, but that we may or may not end up actually producing a
document for it depending on how discussions go in the WG, and that if
we did produce a document, the scope would be decided by the WG?
More broadly, would you mind please clarifying exactly what this section
will imply for the WG (see below for more details on my question):
> The working group will produce one or more documents on the following
> work item topics:
>
> * The eBPF instruction set architecture (ISA) that defines the
> instructions and low-level virtual machine for eBPF programs,
>
> * Verifier expectations and building blocks for allowing safe execution
> of untrusted eBPF programs,
>
> * the BPF Type Format (BTF) that defines debug information and
> introspection capabilities for eBPF programs,
>
> * the eBPF bindings for the ELF executable file format,
>
> * the platform support ABI, including calling convention, linker
> requirements, and relocations,
>
> * Cross-platform map types allowing native data structure access from
> eBPF programs,
>
> * Cross-platform helper functions, such as for manipulation of maps,
>
> * Cross-platform eBPF program types that define the higher level
> execution environment for eBPF programs,
>
> * and an architecture and framework informational document.
As far as I understand, if a topic is missing from this section, it
doesn't automatically mean that it's out of scope for the WG to produce
a document for it. If that's the case, and part of the job of the WG
will be to specify what is actually in scope regardless of what's
enumerated here, I'm not quite following why this section is necessary
beyond providing the reader with some informal context on what BPF is in
general.
Thanks in advance for explaining these concepts to an IETF noobie.
> > Otherwise, if the intended meaning in the draft charter is to cover 2), I would
> > like to note that, usually and conventionally ELF extensions introduced by
> > architectures (and operating systems in the ELF sense)
> > are:
> >
> > - Part of the psABI (chapter Object Files).
> >
> > - Not standards, in the sense that these are not handled by
> > standardization bodies.
> >
> > - Maintained by corporations, associations, and/or community groups, and
> > published in one form or another. A few examples of both arch and os
> > extensions:
> >
> > + The x86_64 psABI, including the ELF bits, is maintained by Intel
> > (mainly by HJ Lu, a toolchain hacker) and available in a git repo in
> > gitlab [1].
> >
> > + The risc-v psABI, including the ELF bits, is maintained by I believe
> > RISC-V International and the community, and is available in a git
> > repo in github [2].
> >
> > + The GNU extensions to the gABI, including the ELF bits, is
> > maintained by GNU hackers and available in a git repo in sourceware
> > [3].
> >
> > + The llvm extensions to ELF, which in this case take the form of an
> > "os" in the ELF sense even if it is not an operating system, are
> > maintained by the LLVM project and available in the
> > docs/Extensions.rst file in the llvm source distribution.
> >
> > Note that more often than not this is kept quite informally, without
> > the need of much bureocratic overhead. A git repo in github or the
> > like, maintained by the eBPF foundation or similar, would be more than
> > enough IMO.
>
> To ensure interoperability, I'd want a slightly more formal specification.
I understand the desire and need for ensuring interoperability, but if
specifying a BPF ELF extension would be the exception to the rule for
the entirety of the rest of the industry when it comes to ELF, I think
we should consider also being explicit about what's different for BPF.
> > - Open to suggestions and contributions from the community, vendors,
> > implementors, etc. This usually involves having a mailing list where
> > such suggestions can be sent an discussed. Almost always very little
> > discussion is required, if any, because the proposed extension has
> > already been agreed and worked on by the involved parties: toolchains,
> > consumers, etc.
> >
> > - Continuously evolving.
> >
> > So, would the IETF working group be able to accomodate something like the
> > above? For example, once a document is officially published by the working
> > group, how easy is it to modify it and make a new version to incorporate
> > something new, like a new relocation type for example?
> > (Apologies for my total ignorance of IETF business :/)
>
> There's 3 ways:
> 1) The IETF can publish an extension spec with additional optional features.
> 2) The IETF can publish a replacement to the original (not usually desirable)
> 3) The IETF can define a process for other organizations or vendors to create
> their own extensions, and some mechanism for ensuring that two such
> extensions don't collide using the same codepoint. This is what the charter
> implies the WG should do.
This certainly seems useful, but it also feels like ELF is kind of a
special case here given that it was originally published as part of Sys
V, and there are no formally specified extensions for other much larger
architectures. I may be missing a lot of context here, so thanks in
advance again for filling in any gaps.
- David
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-17 21:00 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-17 21:00 UTC (permalink / raw)
To: Dave Thaler; +Cc: Jose E. Marchesi, Dave Thaler, bpf@ietf.org, bpf
On Wed, May 17, 2023 at 06:19:42PM +0000, Dave Thaler wrote:
> Jose E. Marchesi wrote:
> > As I mentioned during your talk at LSF/MM/BPF, I think that two items may be
> > a bit confusing, and worth to clarify:
> >
> > * the eBPF bindings for the ELF executable file format,
> >
> > What does "eBPF bindings" mean in this context? I think there are at least two
> > possible interpretations:
> >
> > 1) The way BPF uses ELF, not impacting internal ELF structures. For
> > example the special section names that a conformant BPF loader
> > expects and understands, such as ".probes", or rules on how to use
> > the symbols visibility, or how notes are used (if they are used) etc
> >
> > 2) The ELF extensions that BPF introduces (and may introduce at some
> > point) as an architecture, such as machine number, section types,
> > special section indices, segment types, relocation types, symbol
> > types, symbol bindings, additional section and segment flags, file
> > flags, and perhaps structures of the contents of some special
> > sections.
>
> See https://www.ietf.org/archive/id/draft-thaler-bpf-elf-00.html
> It includes the values used in the ELF header, section naming,
> use of the "license" and "version" sections, meaning of "maps" and
> ".maps" sections, etc.
I have what may be a silly question: The document you linked specifies,
"This specification is a [sic] extension to the ELF file format as
specified in Chapter 4 of the System V Application Binary Interface
[ELF]."
What does it mean exactly for an IETF-published BPF ELF extension to be
an extension of a specification from a totally separate standards body
(in this case, the System V release 4 ABI / Tool Interface Standard
(TIS))? In other words, is it normal for extensions to be specified in
external / separate standards bodies from where the original
specification is defined? It seems like that could potentially result in
a confusing outcome if the original standards body could itself
eventually choose to publish its own extension which conflicts with the
IETF. That won't happen for Sys V of course, but in general it seems odd
for us to publish an extension for a specification that was defined in
the System V ABI instead of the IETF, and it seems like a situation for
which following the existing contours for x86_64, ARM, etc might make
sense.
> > If the intended meaning of that point in the draft is 1), then I would suggest to
> > change the wording to something like:
> >
> > * the requirements and expectations that ELF files shall fulfill so they
> > can be handled by conformant eBPF implementations.
>
> My own opinion is to leave the more detailed definition of what belongs
> in the ELF spec vs another document up to the WG to define rather than
> baking it into the charter.
I tend to agree, but that seems to suggest that we should remove this
line from the charter, and instead leave it up to the WG to determine if
it should be included:
* the eBPF bindings for the ELF executable file format,
Or is your point rather that the line in the charter as it exists now is
really saying that discussing ELF *in general* is in scope for the
working group, but that we may or may not end up actually producing a
document for it depending on how discussions go in the WG, and that if
we did produce a document, the scope would be decided by the WG?
More broadly, would you mind please clarifying exactly what this section
will imply for the WG (see below for more details on my question):
> The working group will produce one or more documents on the following
> work item topics:
>
> * The eBPF instruction set architecture (ISA) that defines the
> instructions and low-level virtual machine for eBPF programs,
>
> * Verifier expectations and building blocks for allowing safe execution
> of untrusted eBPF programs,
>
> * the BPF Type Format (BTF) that defines debug information and
> introspection capabilities for eBPF programs,
>
> * the eBPF bindings for the ELF executable file format,
>
> * the platform support ABI, including calling convention, linker
> requirements, and relocations,
>
> * Cross-platform map types allowing native data structure access from
> eBPF programs,
>
> * Cross-platform helper functions, such as for manipulation of maps,
>
> * Cross-platform eBPF program types that define the higher level
> execution environment for eBPF programs,
>
> * and an architecture and framework informational document.
As far as I understand, if a topic is missing from this section, it
doesn't automatically mean that it's out of scope for the WG to produce
a document for it. If that's the case, and part of the job of the WG
will be to specify what is actually in scope regardless of what's
enumerated here, I'm not quite following why this section is necessary
beyond providing the reader with some informal context on what BPF is in
general.
Thanks in advance for explaining these concepts to an IETF noobie.
> > Otherwise, if the intended meaning in the draft charter is to cover 2), I would
> > like to note that, usually and conventionally ELF extensions introduced by
> > architectures (and operating systems in the ELF sense)
> > are:
> >
> > - Part of the psABI (chapter Object Files).
> >
> > - Not standards, in the sense that these are not handled by
> > standardization bodies.
> >
> > - Maintained by corporations, associations, and/or community groups, and
> > published in one form or another. A few examples of both arch and os
> > extensions:
> >
> > + The x86_64 psABI, including the ELF bits, is maintained by Intel
> > (mainly by HJ Lu, a toolchain hacker) and available in a git repo in
> > gitlab [1].
> >
> > + The risc-v psABI, including the ELF bits, is maintained by I believe
> > RISC-V International and the community, and is available in a git
> > repo in github [2].
> >
> > + The GNU extensions to the gABI, including the ELF bits, is
> > maintained by GNU hackers and available in a git repo in sourceware
> > [3].
> >
> > + The llvm extensions to ELF, which in this case take the form of an
> > "os" in the ELF sense even if it is not an operating system, are
> > maintained by the LLVM project and available in the
> > docs/Extensions.rst file in the llvm source distribution.
> >
> > Note that more often than not this is kept quite informally, without
> > the need of much bureocratic overhead. A git repo in github or the
> > like, maintained by the eBPF foundation or similar, would be more than
> > enough IMO.
>
> To ensure interoperability, I'd want a slightly more formal specification.
I understand the desire and need for ensuring interoperability, but if
specifying a BPF ELF extension would be the exception to the rule for
the entirety of the rest of the industry when it comes to ELF, I think
we should consider also being explicit about what's different for BPF.
> > - Open to suggestions and contributions from the community, vendors,
> > implementors, etc. This usually involves having a mailing list where
> > such suggestions can be sent an discussed. Almost always very little
> > discussion is required, if any, because the proposed extension has
> > already been agreed and worked on by the involved parties: toolchains,
> > consumers, etc.
> >
> > - Continuously evolving.
> >
> > So, would the IETF working group be able to accomodate something like the
> > above? For example, once a document is officially published by the working
> > group, how easy is it to modify it and make a new version to incorporate
> > something new, like a new relocation type for example?
> > (Apologies for my total ignorance of IETF business :/)
>
> There's 3 ways:
> 1) The IETF can publish an extension spec with additional optional features.
> 2) The IETF can publish a replacement to the original (not usually desirable)
> 3) The IETF can define a process for other organizations or vendors to create
> their own extensions, and some mechanism for ensuring that two such
> extensions don't collide using the same codepoint. This is what the charter
> implies the WG should do.
This certainly seems useful, but it also feels like ELF is kind of a
special case here given that it was originally published as part of Sys
V, and there are no formally specified extensions for other much larger
architectures. I may be missing a lot of context here, so thanks in
advance again for filling in any gaps.
- David
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-17 21:13 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-17 21:13 UTC (permalink / raw)
To: David Vernet; +Cc: Jose E. Marchesi, Dave Thaler, bpf@ietf.org, bpf
> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Wednesday, May 17, 2023 2:00 PM
> To: Dave Thaler <dthaler@microsoft.com>
> Cc: Jose E. Marchesi <jemarch@gnu.org>; Dave Thaler
> <dthaler=40microsoft.com@dmarc.ietf.org>; bpf@ietf.org; bpf
> <bpf@vger.kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
> On Wed, May 17, 2023 at 06:19:42PM +0000, Dave Thaler wrote:
> > Jose E. Marchesi wrote:
> > > As I mentioned during your talk at LSF/MM/BPF, I think that two
> > > items may be a bit confusing, and worth to clarify:
> > >
> > > * the eBPF bindings for the ELF executable file format,
> > >
> > > What does "eBPF bindings" mean in this context? I think there are
> > > at least two possible interpretations:
> > >
> > > 1) The way BPF uses ELF, not impacting internal ELF structures. For
> > > example the special section names that a conformant BPF loader
> > > expects and understands, such as ".probes", or rules on how to use
> > > the symbols visibility, or how notes are used (if they are used)
> > > etc
> > >
> > > 2) The ELF extensions that BPF introduces (and may introduce at some
> > > point) as an architecture, such as machine number, section types,
> > > special section indices, segment types, relocation types, symbol
> > > types, symbol bindings, additional section and segment flags, file
> > > flags, and perhaps structures of the contents of some special
> > > sections.
> >
> > See
> >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Farchive%2Fid%2Fdraft-thaler-bpf-elf-
> 00.html&data=05%7C01%7C
> >
> dthaler%40microsoft.com%7Cddd426f86cb4489c17d108db5719c1cc%7C72f9
> 88bf8
> >
> 6f141af91ab2d7cd011db47%7C1%7C0%7C638199540383552382%7CUnkno
> wn%7CTWFpb
> >
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0
> >
> %3D%7C3000%7C%7C%7C&sdata=hM81uNUjJP2J46eSs6tLPi7B82Z7EhlJrGUS
> 2YNo9Bk%
> > 3D&reserved=0 It includes the values used in the ELF header, section
> > naming, use of the "license" and "version" sections, meaning of "maps"
> > and ".maps" sections, etc.
>
> I have what may be a silly question: The document you linked specifies,
>
> "This specification is a [sic] extension to the ELF file format as specified in
> Chapter 4 of the System V Application Binary Interface [ELF]."
>
> What does it mean exactly for an IETF-published BPF ELF extension to be an
> extension of a specification from a totally separate standards body (in this case,
> the System V release 4 ABI / Tool Interface Standard (TIS))?
Perhaps "extension" is not the correct word. At least that word is not in the
draft charter. If the document is changed to say "bindings" then it would be
consistent with the draft charter, but there may be a better term.
As Alexei explained at LSF/MM/BPF last week, this isn't a change to the ELF
spec, and my understanding is that it needn't be done by the ELF standards body,
but I am not the expert there.
> In other words, is it
> normal for extensions to be specified in external / separate standards bodies
> from where the original specification is defined? It seems like that could
> potentially result in a confusing outcome if the original standards body could
> itself eventually choose to publish its own extension which conflicts with the
> IETF. That won't happen for Sys V of course, but in general it seems odd for us
> to publish an extension for a specification that was defined in the System V ABI
> instead of the IETF, and it seems like a situation for which following the existing
> contours for x86_64, ARM, etc might make sense.
>
> > > If the intended meaning of that point in the draft is 1), then I
> > > would suggest to change the wording to something like:
> > >
> > > * the requirements and expectations that ELF files shall fulfill so they
> > > can be handled by conformant eBPF implementations.
> >
> > My own opinion is to leave the more detailed definition of what
> > belongs in the ELF spec vs another document up to the WG to define
> > rather than baking it into the charter.
>
> I tend to agree, but that seems to suggest that we should remove this line from
> the charter, and instead leave it up to the WG to determine if it should be
> included:
>
> * the eBPF bindings for the ELF executable file format,
Removing it would be problematic in my view (unless we remove a phrase
Warren commented on) since the draft charter says:
> The working group shall not adopt new work until these
> documents have progressed to working group last call.
So if the WG does need to do it, it couldn't adopt it without keeping this bullet.
> Or is your point rather that the line in the charter as it exists now is really
> saying that discussing ELF *in general* is in scope for the working group, but
> that we may or may not end up actually producing a document for it depending
> on how discussions go in the WG, and that if we did produce a document, the
> scope would be decided by the WG?
Yes, that would be another valid interpretation. My opinion is that the IETF
should produce a document.
> More broadly, would you mind please clarifying exactly what this section will
> imply for the WG (see below for more details on my question):
>
> > The working group will produce one or more documents on the following
> > work item topics:
> >
> > * The eBPF instruction set architecture (ISA) that defines the
> > instructions and low-level virtual machine for eBPF programs,
> >
> > * Verifier expectations and building blocks for allowing safe execution
> > of untrusted eBPF programs,
> >
> > * the BPF Type Format (BTF) that defines debug information and
> > introspection capabilities for eBPF programs,
> >
> > * the eBPF bindings for the ELF executable file format,
> >
> > * the platform support ABI, including calling convention, linker
> > requirements, and relocations,
> >
> > * Cross-platform map types allowing native data structure access from
> > eBPF programs,
> >
> > * Cross-platform helper functions, such as for manipulation of maps,
> >
> > * Cross-platform eBPF program types that define the higher level
> > execution environment for eBPF programs,
> >
> > * and an architecture and framework informational document.
>
> As far as I understand, if a topic is missing from this section, it doesn't
> automatically mean that it's out of scope for the WG to produce a document
> for it. If that's the case, and part of the job of the WG will be to specify what is
> actually in scope regardless of what's enumerated here, I'm not quite following
> why this section is necessary beyond providing the reader with some informal
> context on what BPF is in general.
The above section is typical in IETF WG charters. And the bit I quoted earlier
about not doing additional things as work items until this list is done, is also
somewhat typical.
> Thanks in advance for explaining these concepts to an IETF noobie.
>
> > > Otherwise, if the intended meaning in the draft charter is to cover
> > > 2), I would like to note that, usually and conventionally ELF
> > > extensions introduced by architectures (and operating systems in the
> > > ELF sense)
> > > are:
> > >
> > > - Part of the psABI (chapter Object Files).
> > >
> > > - Not standards, in the sense that these are not handled by
> > > standardization bodies.
> > >
> > > - Maintained by corporations, associations, and/or community groups, and
> > > published in one form or another. A few examples of both arch and os
> > > extensions:
> > >
> > > + The x86_64 psABI, including the ELF bits, is maintained by Intel
> > > (mainly by HJ Lu, a toolchain hacker) and available in a git repo in
> > > gitlab [1].
> > >
> > > + The risc-v psABI, including the ELF bits, is maintained by I believe
> > > RISC-V International and the community, and is available in a git
> > > repo in github [2].
> > >
> > > + The GNU extensions to the gABI, including the ELF bits, is
> > > maintained by GNU hackers and available in a git repo in sourceware
> > > [3].
> > >
> > > + The llvm extensions to ELF, which in this case take the form of an
> > > "os" in the ELF sense even if it is not an operating system, are
> > > maintained by the LLVM project and available in the
> > > docs/Extensions.rst file in the llvm source distribution.
> > >
> > > Note that more often than not this is kept quite informally, without
> > > the need of much bureocratic overhead. A git repo in github or the
> > > like, maintained by the eBPF foundation or similar, would be more than
> > > enough IMO.
> >
> > To ensure interoperability, I'd want a slightly more formal specification.
>
> I understand the desire and need for ensuring interoperability, but if specifying
> a BPF ELF extension would be the exception to the rule for the entirety of the
> rest of the industry when it comes to ELF, I think we should consider also being
> explicit about what's different for BPF.
Others probably understand ELF processes better than I do. But I think
the belief is that it's not an extension. If there is, and there's another place
it needs to be done, then acknowledging that in terms of who the WG will
interact with might be helpful.
> > > - Open to suggestions and contributions from the community, vendors,
> > > implementors, etc. This usually involves having a mailing list where
> > > such suggestions can be sent an discussed. Almost always very little
> > > discussion is required, if any, because the proposed extension has
> > > already been agreed and worked on by the involved parties: toolchains,
> > > consumers, etc.
> > >
> > > - Continuously evolving.
> > >
> > > So, would the IETF working group be able to accomodate something
> > > like the above? For example, once a document is officially
> > > published by the working group, how easy is it to modify it and make
> > > a new version to incorporate something new, like a new relocation type for
> example?
> > > (Apologies for my total ignorance of IETF business :/)
> >
> > There's 3 ways:
> > 1) The IETF can publish an extension spec with additional optional features.
> > 2) The IETF can publish a replacement to the original (not usually
> > desirable)
> > 3) The IETF can define a process for other organizations or vendors to
> > create their own extensions, and some mechanism for ensuring that two
> > such extensions don't collide using the same codepoint. This is what
> > the charter implies the WG should do.
>
> This certainly seems useful, but it also feels like ELF is kind of a special case
> here given that it was originally published as part of Sys V, and there are no
> formally specified extensions for other much larger architectures. I may be
> missing a lot of context here, so thanks in advance again for filling in any gaps.
>
> - David
Dave
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-17 21:13 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-17 21:13 UTC (permalink / raw)
To: David Vernet; +Cc: Jose E. Marchesi, Dave Thaler, bpf@ietf.org, bpf
> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Wednesday, May 17, 2023 2:00 PM
> To: Dave Thaler <dthaler@microsoft.com>
> Cc: Jose E. Marchesi <jemarch@gnu.org>; Dave Thaler
> <dthaler=40microsoft.com@dmarc.ietf.org>; bpf@ietf.org; bpf
> <bpf@vger.kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
> On Wed, May 17, 2023 at 06:19:42PM +0000, Dave Thaler wrote:
> > Jose E. Marchesi wrote:
> > > As I mentioned during your talk at LSF/MM/BPF, I think that two
> > > items may be a bit confusing, and worth to clarify:
> > >
> > > * the eBPF bindings for the ELF executable file format,
> > >
> > > What does "eBPF bindings" mean in this context? I think there are
> > > at least two possible interpretations:
> > >
> > > 1) The way BPF uses ELF, not impacting internal ELF structures. For
> > > example the special section names that a conformant BPF loader
> > > expects and understands, such as ".probes", or rules on how to use
> > > the symbols visibility, or how notes are used (if they are used)
> > > etc
> > >
> > > 2) The ELF extensions that BPF introduces (and may introduce at some
> > > point) as an architecture, such as machine number, section types,
> > > special section indices, segment types, relocation types, symbol
> > > types, symbol bindings, additional section and segment flags, file
> > > flags, and perhaps structures of the contents of some special
> > > sections.
> >
> > See
> >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Farchive%2Fid%2Fdraft-thaler-bpf-elf-
> 00.html&data=05%7C01%7C
> >
> dthaler%40microsoft.com%7Cddd426f86cb4489c17d108db5719c1cc%7C72f9
> 88bf8
> >
> 6f141af91ab2d7cd011db47%7C1%7C0%7C638199540383552382%7CUnkno
> wn%7CTWFpb
> >
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0
> >
> %3D%7C3000%7C%7C%7C&sdata=hM81uNUjJP2J46eSs6tLPi7B82Z7EhlJrGUS
> 2YNo9Bk%
> > 3D&reserved=0 It includes the values used in the ELF header, section
> > naming, use of the "license" and "version" sections, meaning of "maps"
> > and ".maps" sections, etc.
>
> I have what may be a silly question: The document you linked specifies,
>
> "This specification is a [sic] extension to the ELF file format as specified in
> Chapter 4 of the System V Application Binary Interface [ELF]."
>
> What does it mean exactly for an IETF-published BPF ELF extension to be an
> extension of a specification from a totally separate standards body (in this case,
> the System V release 4 ABI / Tool Interface Standard (TIS))?
Perhaps "extension" is not the correct word. At least that word is not in the
draft charter. If the document is changed to say "bindings" then it would be
consistent with the draft charter, but there may be a better term.
As Alexei explained at LSF/MM/BPF last week, this isn't a change to the ELF
spec, and my understanding is that it needn't be done by the ELF standards body,
but I am not the expert there.
> In other words, is it
> normal for extensions to be specified in external / separate standards bodies
> from where the original specification is defined? It seems like that could
> potentially result in a confusing outcome if the original standards body could
> itself eventually choose to publish its own extension which conflicts with the
> IETF. That won't happen for Sys V of course, but in general it seems odd for us
> to publish an extension for a specification that was defined in the System V ABI
> instead of the IETF, and it seems like a situation for which following the existing
> contours for x86_64, ARM, etc might make sense.
>
> > > If the intended meaning of that point in the draft is 1), then I
> > > would suggest to change the wording to something like:
> > >
> > > * the requirements and expectations that ELF files shall fulfill so they
> > > can be handled by conformant eBPF implementations.
> >
> > My own opinion is to leave the more detailed definition of what
> > belongs in the ELF spec vs another document up to the WG to define
> > rather than baking it into the charter.
>
> I tend to agree, but that seems to suggest that we should remove this line from
> the charter, and instead leave it up to the WG to determine if it should be
> included:
>
> * the eBPF bindings for the ELF executable file format,
Removing it would be problematic in my view (unless we remove a phrase
Warren commented on) since the draft charter says:
> The working group shall not adopt new work until these
> documents have progressed to working group last call.
So if the WG does need to do it, it couldn't adopt it without keeping this bullet.
> Or is your point rather that the line in the charter as it exists now is really
> saying that discussing ELF *in general* is in scope for the working group, but
> that we may or may not end up actually producing a document for it depending
> on how discussions go in the WG, and that if we did produce a document, the
> scope would be decided by the WG?
Yes, that would be another valid interpretation. My opinion is that the IETF
should produce a document.
> More broadly, would you mind please clarifying exactly what this section will
> imply for the WG (see below for more details on my question):
>
> > The working group will produce one or more documents on the following
> > work item topics:
> >
> > * The eBPF instruction set architecture (ISA) that defines the
> > instructions and low-level virtual machine for eBPF programs,
> >
> > * Verifier expectations and building blocks for allowing safe execution
> > of untrusted eBPF programs,
> >
> > * the BPF Type Format (BTF) that defines debug information and
> > introspection capabilities for eBPF programs,
> >
> > * the eBPF bindings for the ELF executable file format,
> >
> > * the platform support ABI, including calling convention, linker
> > requirements, and relocations,
> >
> > * Cross-platform map types allowing native data structure access from
> > eBPF programs,
> >
> > * Cross-platform helper functions, such as for manipulation of maps,
> >
> > * Cross-platform eBPF program types that define the higher level
> > execution environment for eBPF programs,
> >
> > * and an architecture and framework informational document.
>
> As far as I understand, if a topic is missing from this section, it doesn't
> automatically mean that it's out of scope for the WG to produce a document
> for it. If that's the case, and part of the job of the WG will be to specify what is
> actually in scope regardless of what's enumerated here, I'm not quite following
> why this section is necessary beyond providing the reader with some informal
> context on what BPF is in general.
The above section is typical in IETF WG charters. And the bit I quoted earlier
about not doing additional things as work items until this list is done, is also
somewhat typical.
> Thanks in advance for explaining these concepts to an IETF noobie.
>
> > > Otherwise, if the intended meaning in the draft charter is to cover
> > > 2), I would like to note that, usually and conventionally ELF
> > > extensions introduced by architectures (and operating systems in the
> > > ELF sense)
> > > are:
> > >
> > > - Part of the psABI (chapter Object Files).
> > >
> > > - Not standards, in the sense that these are not handled by
> > > standardization bodies.
> > >
> > > - Maintained by corporations, associations, and/or community groups, and
> > > published in one form or another. A few examples of both arch and os
> > > extensions:
> > >
> > > + The x86_64 psABI, including the ELF bits, is maintained by Intel
> > > (mainly by HJ Lu, a toolchain hacker) and available in a git repo in
> > > gitlab [1].
> > >
> > > + The risc-v psABI, including the ELF bits, is maintained by I believe
> > > RISC-V International and the community, and is available in a git
> > > repo in github [2].
> > >
> > > + The GNU extensions to the gABI, including the ELF bits, is
> > > maintained by GNU hackers and available in a git repo in sourceware
> > > [3].
> > >
> > > + The llvm extensions to ELF, which in this case take the form of an
> > > "os" in the ELF sense even if it is not an operating system, are
> > > maintained by the LLVM project and available in the
> > > docs/Extensions.rst file in the llvm source distribution.
> > >
> > > Note that more often than not this is kept quite informally, without
> > > the need of much bureocratic overhead. A git repo in github or the
> > > like, maintained by the eBPF foundation or similar, would be more than
> > > enough IMO.
> >
> > To ensure interoperability, I'd want a slightly more formal specification.
>
> I understand the desire and need for ensuring interoperability, but if specifying
> a BPF ELF extension would be the exception to the rule for the entirety of the
> rest of the industry when it comes to ELF, I think we should consider also being
> explicit about what's different for BPF.
Others probably understand ELF processes better than I do. But I think
the belief is that it's not an extension. If there is, and there's another place
it needs to be done, then acknowledging that in terms of who the WG will
interact with might be helpful.
> > > - Open to suggestions and contributions from the community, vendors,
> > > implementors, etc. This usually involves having a mailing list where
> > > such suggestions can be sent an discussed. Almost always very little
> > > discussion is required, if any, because the proposed extension has
> > > already been agreed and worked on by the involved parties: toolchains,
> > > consumers, etc.
> > >
> > > - Continuously evolving.
> > >
> > > So, would the IETF working group be able to accomodate something
> > > like the above? For example, once a document is officially
> > > published by the working group, how easy is it to modify it and make
> > > a new version to incorporate something new, like a new relocation type for
> example?
> > > (Apologies for my total ignorance of IETF business :/)
> >
> > There's 3 ways:
> > 1) The IETF can publish an extension spec with additional optional features.
> > 2) The IETF can publish a replacement to the original (not usually
> > desirable)
> > 3) The IETF can define a process for other organizations or vendors to
> > create their own extensions, and some mechanism for ensuring that two
> > such extensions don't collide using the same codepoint. This is what
> > the charter implies the WG should do.
>
> This certainly seems useful, but it also feels like ELF is kind of a special case
> here given that it was originally published as part of Sys V, and there are no
> formally specified extensions for other much larger architectures. I may be
> missing a lot of context here, so thanks in advance again for filling in any gaps.
>
> - David
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-18 17:33 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-18 17:33 UTC (permalink / raw)
To: Dave Thaler; +Cc: bpf@ietf.org, bpf
Hi Dave.
> Jose E. Marchesi wrote:
>> As I mentioned during your talk at LSF/MM/BPF, I think that two items may be
>> a bit confusing, and worth to clarify:
>>
>> * the eBPF bindings for the ELF executable file format,
>>
>> What does "eBPF bindings" mean in this context? I think there are at least two
>> possible interpretations:
>>
>> 1) The way BPF uses ELF, not impacting internal ELF structures. For
>> example the special section names that a conformant BPF loader
>> expects and understands, such as ".probes", or rules on how to use
>> the symbols visibility, or how notes are used (if they are used) etc
>>
>> 2) The ELF extensions that BPF introduces (and may introduce at some
>> point) as an architecture, such as machine number, section types,
>> special section indices, segment types, relocation types, symbol
>> types, symbol bindings, additional section and segment flags, file
>> flags, and perhaps structures of the contents of some special
>> sections.
>
> See https://www.ietf.org/archive/id/draft-thaler-bpf-elf-00.html
> It includes the values used in the ELF header, section naming,
> use of the "license" and "version" sections, meaning of "maps" and
> ".maps" sections, etc.
Right, so it is 2). You intend to actually standardize the ELF
extensions.
>> If the intended meaning of that point in the draft is 1), then I would suggest to
>> change the wording to something like:
>>
>> * the requirements and expectations that ELF files shall fulfill so they
>> can be handled by conformant eBPF implementations.
>
> My own opinion is to leave the more detailed definition of what belongs
> in the ELF spec vs another document up to the WG to define rather than
> baking it into the charter.
Sure, that suggestion was provided in case your intention was 1), not 2)
:)
>> Otherwise, if the intended meaning in the draft charter is to cover 2), I would
>> like to note that, usually and conventionally ELF extensions introduced by
>> architectures (and operating systems in the ELF sense)
>> are:
>>
>> - Part of the psABI (chapter Object Files).
>>
>> - Not standards, in the sense that these are not handled by
>> standardization bodies.
>>
>> - Maintained by corporations, associations, and/or community groups, and
>> published in one form or another. A few examples of both arch and os
>> extensions:
>>
>> + The x86_64 psABI, including the ELF bits, is maintained by Intel
>> (mainly by HJ Lu, a toolchain hacker) and available in a git repo in
>> gitlab [1].
>>
>> + The risc-v psABI, including the ELF bits, is maintained by I believe
>> RISC-V International and the community, and is available in a git
>> repo in github [2].
>>
>> + The GNU extensions to the gABI, including the ELF bits, is
>> maintained by GNU hackers and available in a git repo in sourceware
>> [3].
>>
>> + The llvm extensions to ELF, which in this case take the form of an
>> "os" in the ELF sense even if it is not an operating system, are
>> maintained by the LLVM project and available in the
>> docs/Extensions.rst file in the llvm source distribution.
>>
>> Note that more often than not this is kept quite informally, without
>> the need of much bureocratic overhead. A git repo in github or the
>> like, maintained by the eBPF foundation or similar, would be more than
>> enough IMO.
>
> To ensure interoperability, I'd want a slightly more formal specification.
I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
powerpc architectures, along with their variants, handle their ELF
extensions and psABI, ensures interoperability good enough for the
problem at hand, but ok. I'm definitely not an expert in these matters.
>> - Open to suggestions and contributions from the community, vendors,
>> implementors, etc. This usually involves having a mailing list where
>> such suggestions can be sent an discussed. Almost always very little
>> discussion is required, if any, because the proposed extension has
>> already been agreed and worked on by the involved parties: toolchains,
>> consumers, etc.
>>
>> - Continuously evolving.
>>
>> So, would the IETF working group be able to accomodate something like the
>> above? For example, once a document is officially published by the working
>> group, how easy is it to modify it and make a new version to incorporate
>> something new, like a new relocation type for example?
>> (Apologies for my total ignorance of IETF business :/)
>
> There's 3 ways:
> 1) The IETF can publish an extension spec with additional optional
> features.
I don't think adding new relocation type, as an example of the kind of
changes that ABIs regularly are subjected to, qualify as "additional
optional features".
> 2) The IETF can publish a replacement to the original (not usually
> desirable)
You _will_ need to update that particular document, and probably quite
often.
jemarch@termi:~/gnu/src/x86-64-ABI$ git log --oneline --since="May 18 2022"
b96eaf2 (HEAD -> master, origin/master, origin/HEAD) Remove MPX support
ab1bd26 _BitInt: Update alignment of _BitInt(N) for N > 64
43453ea Clarify R_X86_64_REX_GOTPCRELX transformation
e2387f1 Add link to download latest PDF
b5443bf Fix typo in footnote stating incorrect register range for AVX512
8195730 Add optional __bf16 support
6c2ac6c ABI: Fix typos
8ca4539 Add _BitInt(N) from ISO/IEC WG14 N2763
That is for a very well consolidated and stable architecture such as
x86_64. Now imagine what will happen with something like BPF that is
still in the process of figuring out its own ABI and the way it gets
compiled.
Being very optimistic, would it be OK for IETF and the WG to release,
say ten new versions of the "original" per year?
> 3) The IETF can define a process for other organizations or vendors to
> create their own extensions, and some mechanism for ensuring that two
> such extensions don't collide using the same codepoint. This is what
> the charter implies the WG should do.
What is the precise license under which the document describing the ELF
extensions and the ABI will be distributed?
In particular, does it allow distributing modified versions?
Thanks for the info!
> Dave
>
>> Likewise, of the following item:
>>
>> * the platform support ABI, including calling convention, linker
>> requirements, and relocations,
>>
>> The calling convention and relocations are part of the psABI and usually
>> handled like described above.
>>
>> PS: BPF is obviously not a SysV system, but when it comes to document
>> the ABI, including the ELF bits, I think it would be a good idea to
>> use the same document structure conventionally used by psABI, as
>> Alexei already suggested some time ago. This would be most familiar
>> to people.
>>
>> [1]
>> https://gitlab/.
>> com%2Fx86-psABIs%2Fx86-64-
>> ABI&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f514d
>> 08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6381
>> 99331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
>> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sd
>> ata=SaprU2J9WsyJ5qhcxIGKO2F06YtO%2Bm1Gpjb2SIOApLA%3D&reserved=0
>> [2]
>> https://github/
>> .com%2Friscv-non-isa%2Friscv-elf-psabi-
>> doc%2Freleases%2Fdownload%2Fv1.0%2Friscv-
>> abi.pdf&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f5
>> 14d08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> 38199331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C
>> &sdata=uKqnU93kcu8rZ9Y0gzWdmuHnK9ySPM847%2FDMm6vJNwQ%3D&res
>> erved=0
>> [3] git://sourceware.org/git/gnu-gabi.git
>>
>> --
>> Bpf mailing list
>> Bpf@ietf.org
>> https://www.i/
>> etf.org%2Fmailman%2Flistinfo%2Fbpf&data=05%7C01%7Cdthaler%40microso
>> ft.com%7Cd4f2ef78d9e0475f514d08db56e91312%7C72f988bf86f141af91ab2
>> d7cd011db47%7C1%7C0%7C638199331900533629%7CUnknown%7CTWFpb
>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>> Mn0%3D%7C2000%7C%7C%7C&sdata=W9FXcUwb181VQ6ksF2guASQ5FGtTE
>> KZuE0Yb8cHR9vI%3D&reserved=0
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-18 17:33 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-18 17:33 UTC (permalink / raw)
To: Dave Thaler; +Cc: bpf@ietf.org, bpf
Hi Dave.
> Jose E. Marchesi wrote:
>> As I mentioned during your talk at LSF/MM/BPF, I think that two items may be
>> a bit confusing, and worth to clarify:
>>
>> * the eBPF bindings for the ELF executable file format,
>>
>> What does "eBPF bindings" mean in this context? I think there are at least two
>> possible interpretations:
>>
>> 1) The way BPF uses ELF, not impacting internal ELF structures. For
>> example the special section names that a conformant BPF loader
>> expects and understands, such as ".probes", or rules on how to use
>> the symbols visibility, or how notes are used (if they are used) etc
>>
>> 2) The ELF extensions that BPF introduces (and may introduce at some
>> point) as an architecture, such as machine number, section types,
>> special section indices, segment types, relocation types, symbol
>> types, symbol bindings, additional section and segment flags, file
>> flags, and perhaps structures of the contents of some special
>> sections.
>
> See https://www.ietf.org/archive/id/draft-thaler-bpf-elf-00.html
> It includes the values used in the ELF header, section naming,
> use of the "license" and "version" sections, meaning of "maps" and
> ".maps" sections, etc.
Right, so it is 2). You intend to actually standardize the ELF
extensions.
>> If the intended meaning of that point in the draft is 1), then I would suggest to
>> change the wording to something like:
>>
>> * the requirements and expectations that ELF files shall fulfill so they
>> can be handled by conformant eBPF implementations.
>
> My own opinion is to leave the more detailed definition of what belongs
> in the ELF spec vs another document up to the WG to define rather than
> baking it into the charter.
Sure, that suggestion was provided in case your intention was 1), not 2)
:)
>> Otherwise, if the intended meaning in the draft charter is to cover 2), I would
>> like to note that, usually and conventionally ELF extensions introduced by
>> architectures (and operating systems in the ELF sense)
>> are:
>>
>> - Part of the psABI (chapter Object Files).
>>
>> - Not standards, in the sense that these are not handled by
>> standardization bodies.
>>
>> - Maintained by corporations, associations, and/or community groups, and
>> published in one form or another. A few examples of both arch and os
>> extensions:
>>
>> + The x86_64 psABI, including the ELF bits, is maintained by Intel
>> (mainly by HJ Lu, a toolchain hacker) and available in a git repo in
>> gitlab [1].
>>
>> + The risc-v psABI, including the ELF bits, is maintained by I believe
>> RISC-V International and the community, and is available in a git
>> repo in github [2].
>>
>> + The GNU extensions to the gABI, including the ELF bits, is
>> maintained by GNU hackers and available in a git repo in sourceware
>> [3].
>>
>> + The llvm extensions to ELF, which in this case take the form of an
>> "os" in the ELF sense even if it is not an operating system, are
>> maintained by the LLVM project and available in the
>> docs/Extensions.rst file in the llvm source distribution.
>>
>> Note that more often than not this is kept quite informally, without
>> the need of much bureocratic overhead. A git repo in github or the
>> like, maintained by the eBPF foundation or similar, would be more than
>> enough IMO.
>
> To ensure interoperability, I'd want a slightly more formal specification.
I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
powerpc architectures, along with their variants, handle their ELF
extensions and psABI, ensures interoperability good enough for the
problem at hand, but ok. I'm definitely not an expert in these matters.
>> - Open to suggestions and contributions from the community, vendors,
>> implementors, etc. This usually involves having a mailing list where
>> such suggestions can be sent an discussed. Almost always very little
>> discussion is required, if any, because the proposed extension has
>> already been agreed and worked on by the involved parties: toolchains,
>> consumers, etc.
>>
>> - Continuously evolving.
>>
>> So, would the IETF working group be able to accomodate something like the
>> above? For example, once a document is officially published by the working
>> group, how easy is it to modify it and make a new version to incorporate
>> something new, like a new relocation type for example?
>> (Apologies for my total ignorance of IETF business :/)
>
> There's 3 ways:
> 1) The IETF can publish an extension spec with additional optional
> features.
I don't think adding new relocation type, as an example of the kind of
changes that ABIs regularly are subjected to, qualify as "additional
optional features".
> 2) The IETF can publish a replacement to the original (not usually
> desirable)
You _will_ need to update that particular document, and probably quite
often.
jemarch@termi:~/gnu/src/x86-64-ABI$ git log --oneline --since="May 18 2022"
b96eaf2 (HEAD -> master, origin/master, origin/HEAD) Remove MPX support
ab1bd26 _BitInt: Update alignment of _BitInt(N) for N > 64
43453ea Clarify R_X86_64_REX_GOTPCRELX transformation
e2387f1 Add link to download latest PDF
b5443bf Fix typo in footnote stating incorrect register range for AVX512
8195730 Add optional __bf16 support
6c2ac6c ABI: Fix typos
8ca4539 Add _BitInt(N) from ISO/IEC WG14 N2763
That is for a very well consolidated and stable architecture such as
x86_64. Now imagine what will happen with something like BPF that is
still in the process of figuring out its own ABI and the way it gets
compiled.
Being very optimistic, would it be OK for IETF and the WG to release,
say ten new versions of the "original" per year?
> 3) The IETF can define a process for other organizations or vendors to
> create their own extensions, and some mechanism for ensuring that two
> such extensions don't collide using the same codepoint. This is what
> the charter implies the WG should do.
What is the precise license under which the document describing the ELF
extensions and the ABI will be distributed?
In particular, does it allow distributing modified versions?
Thanks for the info!
> Dave
>
>> Likewise, of the following item:
>>
>> * the platform support ABI, including calling convention, linker
>> requirements, and relocations,
>>
>> The calling convention and relocations are part of the psABI and usually
>> handled like described above.
>>
>> PS: BPF is obviously not a SysV system, but when it comes to document
>> the ABI, including the ELF bits, I think it would be a good idea to
>> use the same document structure conventionally used by psABI, as
>> Alexei already suggested some time ago. This would be most familiar
>> to people.
>>
>> [1]
>> https://gitlab/.
>> com%2Fx86-psABIs%2Fx86-64-
>> ABI&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f514d
>> 08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6381
>> 99331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
>> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sd
>> ata=SaprU2J9WsyJ5qhcxIGKO2F06YtO%2Bm1Gpjb2SIOApLA%3D&reserved=0
>> [2]
>> https://github/
>> .com%2Friscv-non-isa%2Friscv-elf-psabi-
>> doc%2Freleases%2Fdownload%2Fv1.0%2Friscv-
>> abi.pdf&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f5
>> 14d08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> 38199331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C
>> &sdata=uKqnU93kcu8rZ9Y0gzWdmuHnK9ySPM847%2FDMm6vJNwQ%3D&res
>> erved=0
>> [3] git://sourceware.org/git/gnu-gabi.git
>>
>> --
>> Bpf mailing list
>> Bpf@ietf.org
>> https://www.i/
>> etf.org%2Fmailman%2Flistinfo%2Fbpf&data=05%7C01%7Cdthaler%40microso
>> ft.com%7Cd4f2ef78d9e0475f514d08db56e91312%7C72f988bf86f141af91ab2
>> d7cd011db47%7C1%7C0%7C638199331900533629%7CUnknown%7CTWFpb
>> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
>> Mn0%3D%7C2000%7C%7C%7C&sdata=W9FXcUwb181VQ6ksF2guASQ5FGtTE
>> KZuE0Yb8cHR9vI%3D&reserved=0
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-18 19:42 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-18 19:42 UTC (permalink / raw)
To: Jose E. Marchesi; +Cc: bpf@ietf.org, bpf
Jose E. Marchesi <jemarch@gnu.org> wrote:
> I would think that the way the x86_64, aarch64, risc-v, sparc, mips, powerpc
> architectures, along with their variants, handle their ELF extensions and
> psABI, ensures interoperability good enough for the problem at hand, but ok.
> I'm definitely not an expert in these matters.
I am not familiar enough with those to make any comment about that.
> >> - Open to suggestions and contributions from the community, vendors,
> >> implementors, etc. This usually involves having a mailing list where
> >> such suggestions can be sent an discussed. Almost always very little
> >> discussion is required, if any, because the proposed extension has
> >> already been agreed and worked on by the involved parties: toolchains,
> >> consumers, etc.
> >>
> >> - Continuously evolving.
> >>
> >> So, would the IETF working group be able to accomodate something like
> >> the above? For example, once a document is officially published by
> >> the working group, how easy is it to modify it and make a new version
> >> to incorporate something new, like a new relocation type for example?
> >> (Apologies for my total ignorance of IETF business :/)
My point in the options is that a standard can be constructed such that
adding a new codepoint does NOT require making a new version. That's
the point of things like IANA registries. So yes it is straightforward to
accommodate _without_ requiring a new version. One only requires
a new version if there are actually errors in the original, or the original
did not allow an IANA registry or other process for codepoint allocation.
> > There's 3 ways:
> > 1) The IETF can publish an extension spec with additional optional
> > features.
>
> I don't think adding new relocation type, as an example of the kind of
> changes that ABIs regularly are subjected to, qualify as "additional optional
> features".
I'm not familiar enough with existing ones to comment on those.
> > 2) The IETF can publish a replacement to the original (not usually
> > desirable)
>
> You _will_ need to update that particular document, and probably quite
> often.
I'm not convinced of that. Indeed that would be very unusual in the IETF.
Rather the IETF has established patterns of writing documents that obviate
the need to update any single document quite often.
> jemarch@termi:~/gnu/src/x86-64-ABI$ git log --oneline --since="May 18
> 2022"
> b96eaf2 (HEAD -> master, origin/master, origin/HEAD) Remove MPX
> support
> ab1bd26 _BitInt: Update alignment of _BitInt(N) for N > 64
> 43453ea Clarify R_X86_64_REX_GOTPCRELX transformation
> e2387f1 Add link to download latest PDF
> b5443bf Fix typo in footnote stating incorrect register range for AVX512
> 8195730 Add optional __bf16 support
> 6c2ac6c ABI: Fix typos
> 8ca4539 Add _BitInt(N) from ISO/IEC WG14 N2763
Going off of nothing but the text above:
* Fixing typos: this is the job of the RFC editor pass to catch anything that
was missed in the earlier steps. In theory there should be no typos
in an RFC. In practice there is an errata process, but typos are not "often".
* Links to download: Links in references inside the document should be
to stable references. Links to IETF documents themselves often go to
an info page which has links to the various formats of the document
(html, pdf, etc.) along with links to any errata and IPR declarations.
* Adding optional support for something: this is most typically done in
a separate document, not by modifying the original.
The point being that in the IETF processes, documents are updated but
it is not "quite often", and the list you cited doesn't convince me that
an IETF style document would need to be updated "quite often".
> That is for a very well consolidated and stable architecture such as x86_64.
> Now imagine what will happen with something like BPF that is still in the
> process of figuring out its own ABI and the way it gets compiled.
>
> Being very optimistic, would it be OK for IETF and the WG to release, say ten
> new versions of the "original" per year?
My personal opinion: No, I'd consider that a failure of the document process
of the WG if that happened. I can say I've been participating in the IETF
since 1994 in many areas and WGs, published between 55 and 60 RFCs,
and I've never seen anything that would have multiple new versions of the
original per year. I don't expect anything in BPF to be more special than
all the other things I've seen. But maybe it's just me :)
> > 3) The IETF can define a process for other organizations or vendors to
> > create their own extensions, and some mechanism for ensuring that two
> > such extensions don't collide using the same codepoint. This is what
> > the charter implies the WG should do.
>
> What is the precise license under which the document describing the ELF
> extensions and the ABI will be distributed?
> In particular, does it allow distributing modified versions?
See https://datatracker.ietf.org/doc/html/rfc8721 in general, but specifically https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ section 3.
Dave
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-18 19:42 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-18 19:42 UTC (permalink / raw)
To: Jose E. Marchesi; +Cc: bpf@ietf.org, bpf
Jose E. Marchesi <jemarch@gnu.org> wrote:
> I would think that the way the x86_64, aarch64, risc-v, sparc, mips, powerpc
> architectures, along with their variants, handle their ELF extensions and
> psABI, ensures interoperability good enough for the problem at hand, but ok.
> I'm definitely not an expert in these matters.
I am not familiar enough with those to make any comment about that.
> >> - Open to suggestions and contributions from the community, vendors,
> >> implementors, etc. This usually involves having a mailing list where
> >> such suggestions can be sent an discussed. Almost always very little
> >> discussion is required, if any, because the proposed extension has
> >> already been agreed and worked on by the involved parties: toolchains,
> >> consumers, etc.
> >>
> >> - Continuously evolving.
> >>
> >> So, would the IETF working group be able to accomodate something like
> >> the above? For example, once a document is officially published by
> >> the working group, how easy is it to modify it and make a new version
> >> to incorporate something new, like a new relocation type for example?
> >> (Apologies for my total ignorance of IETF business :/)
My point in the options is that a standard can be constructed such that
adding a new codepoint does NOT require making a new version. That's
the point of things like IANA registries. So yes it is straightforward to
accommodate _without_ requiring a new version. One only requires
a new version if there are actually errors in the original, or the original
did not allow an IANA registry or other process for codepoint allocation.
> > There's 3 ways:
> > 1) The IETF can publish an extension spec with additional optional
> > features.
>
> I don't think adding new relocation type, as an example of the kind of
> changes that ABIs regularly are subjected to, qualify as "additional optional
> features".
I'm not familiar enough with existing ones to comment on those.
> > 2) The IETF can publish a replacement to the original (not usually
> > desirable)
>
> You _will_ need to update that particular document, and probably quite
> often.
I'm not convinced of that. Indeed that would be very unusual in the IETF.
Rather the IETF has established patterns of writing documents that obviate
the need to update any single document quite often.
> jemarch@termi:~/gnu/src/x86-64-ABI$ git log --oneline --since="May 18
> 2022"
> b96eaf2 (HEAD -> master, origin/master, origin/HEAD) Remove MPX
> support
> ab1bd26 _BitInt: Update alignment of _BitInt(N) for N > 64
> 43453ea Clarify R_X86_64_REX_GOTPCRELX transformation
> e2387f1 Add link to download latest PDF
> b5443bf Fix typo in footnote stating incorrect register range for AVX512
> 8195730 Add optional __bf16 support
> 6c2ac6c ABI: Fix typos
> 8ca4539 Add _BitInt(N) from ISO/IEC WG14 N2763
Going off of nothing but the text above:
* Fixing typos: this is the job of the RFC editor pass to catch anything that
was missed in the earlier steps. In theory there should be no typos
in an RFC. In practice there is an errata process, but typos are not "often".
* Links to download: Links in references inside the document should be
to stable references. Links to IETF documents themselves often go to
an info page which has links to the various formats of the document
(html, pdf, etc.) along with links to any errata and IPR declarations.
* Adding optional support for something: this is most typically done in
a separate document, not by modifying the original.
The point being that in the IETF processes, documents are updated but
it is not "quite often", and the list you cited doesn't convince me that
an IETF style document would need to be updated "quite often".
> That is for a very well consolidated and stable architecture such as x86_64.
> Now imagine what will happen with something like BPF that is still in the
> process of figuring out its own ABI and the way it gets compiled.
>
> Being very optimistic, would it be OK for IETF and the WG to release, say ten
> new versions of the "original" per year?
My personal opinion: No, I'd consider that a failure of the document process
of the WG if that happened. I can say I've been participating in the IETF
since 1994 in many areas and WGs, published between 55 and 60 RFCs,
and I've never seen anything that would have multiple new versions of the
original per year. I don't expect anything in BPF to be more special than
all the other things I've seen. But maybe it's just me :)
> > 3) The IETF can define a process for other organizations or vendors to
> > create their own extensions, and some mechanism for ensuring that two
> > such extensions don't collide using the same codepoint. This is what
> > the charter implies the WG should do.
>
> What is the precise license under which the document describing the ELF
> extensions and the ABI will be distributed?
> In particular, does it allow distributing modified versions?
See https://datatracker.ietf.org/doc/html/rfc8721 in general, but specifically https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ section 3.
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 16:32 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 16:32 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> Jose E. Marchesi <jemarch@gnu.org> wrote:
> > I would think that the way the x86_64, aarch64, risc-v, sparc, mips, powerpc
> > architectures, along with their variants, handle their ELF extensions and
> > psABI, ensures interoperability good enough for the problem at hand, but ok.
> > I'm definitely not an expert in these matters.
>
> I am not familiar enough with those to make any comment about that.
Hi Dave,
Taking a step back here, perhaps we need to think about all of this more
generically as "ABI", rather than ELF "extensions", "bindings", etc. In
my opinion this would include, at a minimum, the following items from
the current proposed WG charter:
* the eBPF bindings for the ELF executable file format,
* the platform support ABI, including calling convention, linker
requirements, and relocations,
As far as I know (please correct me if I'm wrong), there isn't really a
precedence for standardizing ABIs like this. For example, x86 calling
conventions are not standardized. Solaris, Linux, FreeBSD, macOS, etc
all follow the System V AMD64 ABI, but Microsoft of course does not. As
Jose pointed out, such standards extensions do not exist for psABI ELF
extensions for various architectures either.
While it may be that we do end up needing to standardize these ABIs for
BPF, I'm beginning to think that we should just remove them from the
current WG charter, and consider standardizing them at a later time if
it's clear that it's actually necessary. I think this is especially true
given that we don't seem to be getting any closer to having consensus,
and that we're very short on time given that Erik is going to be
proposing the charter to the rest of the ADs in just two days on 5/25.
Thanks,
David
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 16:32 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 16:32 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> Jose E. Marchesi <jemarch@gnu.org> wrote:
> > I would think that the way the x86_64, aarch64, risc-v, sparc, mips, powerpc
> > architectures, along with their variants, handle their ELF extensions and
> > psABI, ensures interoperability good enough for the problem at hand, but ok.
> > I'm definitely not an expert in these matters.
>
> I am not familiar enough with those to make any comment about that.
Hi Dave,
Taking a step back here, perhaps we need to think about all of this more
generically as "ABI", rather than ELF "extensions", "bindings", etc. In
my opinion this would include, at a minimum, the following items from
the current proposed WG charter:
* the eBPF bindings for the ELF executable file format,
* the platform support ABI, including calling convention, linker
requirements, and relocations,
As far as I know (please correct me if I'm wrong), there isn't really a
precedence for standardizing ABIs like this. For example, x86 calling
conventions are not standardized. Solaris, Linux, FreeBSD, macOS, etc
all follow the System V AMD64 ABI, but Microsoft of course does not. As
Jose pointed out, such standards extensions do not exist for psABI ELF
extensions for various architectures either.
While it may be that we do end up needing to standardize these ABIs for
BPF, I'm beginning to think that we should just remove them from the
current WG charter, and consider standardizing them at a later time if
it's clear that it's actually necessary. I think this is especially true
given that we don't seem to be getting any closer to having consensus,
and that we're very short on time given that Erik is going to be
proposing the charter to the rest of the ADs in just two days on 5/25.
Thanks,
David
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 16:50 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-23 16:50 UTC (permalink / raw)
To: David Vernet
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Tuesday, May 23, 2023 9:32 AM
> To: Dave Thaler <dthaler@microsoft.com>
> Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> Alexei Starovoitov <ast@kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
> On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > powerpc architectures, along with their variants, handle their ELF
> > > extensions and psABI, ensures interoperability good enough for the
> problem at hand, but ok.
> > > I'm definitely not an expert in these matters.
> >
> > I am not familiar enough with those to make any comment about that.
>
> Hi Dave,
>
> Taking a step back here, perhaps we need to think about all of this more
> generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> opinion this would include, at a minimum, the following items from the current
> proposed WG charter:
>
> * the eBPF bindings for the ELF executable file format,
>
> * the platform support ABI, including calling convention, linker
> requirements, and relocations,
>
> As far as I know (please correct me if I'm wrong), there isn't really a precedence
> for standardizing ABIs like this. For example, x86 calling conventions are not
> standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> standards extensions do not exist for psABI ELF extensions for various
> architectures either.
>
> While it may be that we do end up needing to standardize these ABIs for BPF,
> I'm beginning to think that we should just remove them from the current WG
> charter, and consider standardizing them at a later time if it's clear that it's
> actually necessary. I think this is especially true given that we don't seem to be
> getting any closer to having consensus, and that we're very short on time given
> that Erik is going to be proposing the charter to the rest of the ADs in just two
> days on 5/25.
>
> Thanks,
> David
I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
Linux and Windows. We don't want Windows to diverge.
As such, I feel strongly that it is a requirement to be standardized right away.
Hence I would not want this removed from the charter unless there's an effort
to do it somewhere else right away, which would seem to increase the coordination
burden.
Dave
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 16:50 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-23 16:50 UTC (permalink / raw)
To: David Vernet
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Tuesday, May 23, 2023 9:32 AM
> To: Dave Thaler <dthaler@microsoft.com>
> Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> Alexei Starovoitov <ast@kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
> On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > powerpc architectures, along with their variants, handle their ELF
> > > extensions and psABI, ensures interoperability good enough for the
> problem at hand, but ok.
> > > I'm definitely not an expert in these matters.
> >
> > I am not familiar enough with those to make any comment about that.
>
> Hi Dave,
>
> Taking a step back here, perhaps we need to think about all of this more
> generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> opinion this would include, at a minimum, the following items from the current
> proposed WG charter:
>
> * the eBPF bindings for the ELF executable file format,
>
> * the platform support ABI, including calling convention, linker
> requirements, and relocations,
>
> As far as I know (please correct me if I'm wrong), there isn't really a precedence
> for standardizing ABIs like this. For example, x86 calling conventions are not
> standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> standards extensions do not exist for psABI ELF extensions for various
> architectures either.
>
> While it may be that we do end up needing to standardize these ABIs for BPF,
> I'm beginning to think that we should just remove them from the current WG
> charter, and consider standardizing them at a later time if it's clear that it's
> actually necessary. I think this is especially true given that we don't seem to be
> getting any closer to having consensus, and that we're very short on time given
> that Erik is going to be proposing the charter to the rest of the ADs in just two
> days on 5/25.
>
> Thanks,
> David
I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
Linux and Windows. We don't want Windows to diverge.
As such, I feel strongly that it is a requirement to be standardized right away.
Hence I would not want this removed from the charter unless there's an effort
to do it somewhere else right away, which would seem to increase the coordination
burden.
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 17:15 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 17:15 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
> > -----Original Message-----
> > From: David Vernet <void@manifault.com>
> > Sent: Tuesday, May 23, 2023 9:32 AM
> > To: Dave Thaler <dthaler@microsoft.com>
> > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> > Alexei Starovoitov <ast@kernel.org>
> > Subject: Re: [Bpf] IETF BPF working group draft charter
> >
> > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > > powerpc architectures, along with their variants, handle their ELF
> > > > extensions and psABI, ensures interoperability good enough for the
> > problem at hand, but ok.
> > > > I'm definitely not an expert in these matters.
> > >
> > > I am not familiar enough with those to make any comment about that.
> >
> > Hi Dave,
> >
> > Taking a step back here, perhaps we need to think about all of this more
> > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> > opinion this would include, at a minimum, the following items from the current
> > proposed WG charter:
> >
> > * the eBPF bindings for the ELF executable file format,
> >
> > * the platform support ABI, including calling convention, linker
> > requirements, and relocations,
> >
> > As far as I know (please correct me if I'm wrong), there isn't really a precedence
> > for standardizing ABIs like this. For example, x86 calling conventions are not
> > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> > standards extensions do not exist for psABI ELF extensions for various
> > architectures either.
> >
> > While it may be that we do end up needing to standardize these ABIs for BPF,
> > I'm beginning to think that we should just remove them from the current WG
> > charter, and consider standardizing them at a later time if it's clear that it's
> > actually necessary. I think this is especially true given that we don't seem to be
> > getting any closer to having consensus, and that we're very short on time given
> > that Erik is going to be proposing the charter to the rest of the ADs in just two
> > days on 5/25.
> >
> > Thanks,
> > David
>
> I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
> llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
> Linux and Windows. We don't want Windows to diverge.
Be that as it may, as I said before, to my knowledge there's no
precedence at all for standardizing ABI like this. Is there a reason
that you think Windows would diverge if we didn't standardize the ABI?
I realize that I'm essentially saying, "Hey, pretend there's a standard
and don't diverge", but if that's what the entire rest of the industry
has done up until this point with all other psABIs, then it seems like a
reasonable expectation.
> As such, I feel strongly that it is a requirement to be standardized right away.
I have to respectfully disagree. I think there are much bigger fish to
fry, such as standardizing the ISA. Unless we really have a good reason
for diverging from industry norms, standardizing on ABI now feels to me
like we're putting the cart before the horse.
Just to be very clear: I could be totally wrong here, and it could be
very important to deviate from industry norms and standardize ABI as
part of the initial WG charter. However, IMHO, a positive claim like
that needs to come with clear substantiation. The reality is that
deviating from industry norms and standardizing on ABI will have its own
costs and consequences.
> Hence I would not want this removed from the charter unless there's an effort
> to do it somewhere else right away, which would seem to increase the coordination
> burden.
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 17:15 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 17:15 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
> > -----Original Message-----
> > From: David Vernet <void@manifault.com>
> > Sent: Tuesday, May 23, 2023 9:32 AM
> > To: Dave Thaler <dthaler@microsoft.com>
> > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> > Alexei Starovoitov <ast@kernel.org>
> > Subject: Re: [Bpf] IETF BPF working group draft charter
> >
> > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > > powerpc architectures, along with their variants, handle their ELF
> > > > extensions and psABI, ensures interoperability good enough for the
> > problem at hand, but ok.
> > > > I'm definitely not an expert in these matters.
> > >
> > > I am not familiar enough with those to make any comment about that.
> >
> > Hi Dave,
> >
> > Taking a step back here, perhaps we need to think about all of this more
> > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> > opinion this would include, at a minimum, the following items from the current
> > proposed WG charter:
> >
> > * the eBPF bindings for the ELF executable file format,
> >
> > * the platform support ABI, including calling convention, linker
> > requirements, and relocations,
> >
> > As far as I know (please correct me if I'm wrong), there isn't really a precedence
> > for standardizing ABIs like this. For example, x86 calling conventions are not
> > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> > standards extensions do not exist for psABI ELF extensions for various
> > architectures either.
> >
> > While it may be that we do end up needing to standardize these ABIs for BPF,
> > I'm beginning to think that we should just remove them from the current WG
> > charter, and consider standardizing them at a later time if it's clear that it's
> > actually necessary. I think this is especially true given that we don't seem to be
> > getting any closer to having consensus, and that we're very short on time given
> > that Erik is going to be proposing the charter to the rest of the ADs in just two
> > days on 5/25.
> >
> > Thanks,
> > David
>
> I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
> llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
> Linux and Windows. We don't want Windows to diverge.
Be that as it may, as I said before, to my knowledge there's no
precedence at all for standardizing ABI like this. Is there a reason
that you think Windows would diverge if we didn't standardize the ABI?
I realize that I'm essentially saying, "Hey, pretend there's a standard
and don't diverge", but if that's what the entire rest of the industry
has done up until this point with all other psABIs, then it seems like a
reasonable expectation.
> As such, I feel strongly that it is a requirement to be standardized right away.
I have to respectfully disagree. I think there are much bigger fish to
fry, such as standardizing the ISA. Unless we really have a good reason
for diverging from industry norms, standardizing on ABI now feels to me
like we're putting the cart before the horse.
Just to be very clear: I could be totally wrong here, and it could be
very important to deviate from industry norms and standardize ABI as
part of the initial WG charter. However, IMHO, a positive claim like
that needs to come with clear substantiation. The reality is that
deviating from industry norms and standardizing on ABI will have its own
costs and consequences.
> Hence I would not want this removed from the charter unless there's an effort
> to do it somewhere else right away, which would seem to increase the coordination
> burden.
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 19:08 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 19:08 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
On Tue, May 23, 2023 at 12:15:35PM -0500, David Vernet wrote:
> On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
> > > -----Original Message-----
> > > From: David Vernet <void@manifault.com>
> > > Sent: Tuesday, May 23, 2023 9:32 AM
> > > To: Dave Thaler <dthaler@microsoft.com>
> > > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> > > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> > > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> > > Alexei Starovoitov <ast@kernel.org>
> > > Subject: Re: [Bpf] IETF BPF working group draft charter
> > >
> > > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > > > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > > > powerpc architectures, along with their variants, handle their ELF
> > > > > extensions and psABI, ensures interoperability good enough for the
> > > problem at hand, but ok.
> > > > > I'm definitely not an expert in these matters.
> > > >
> > > > I am not familiar enough with those to make any comment about that.
> > >
> > > Hi Dave,
> > >
> > > Taking a step back here, perhaps we need to think about all of this more
> > > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> > > opinion this would include, at a minimum, the following items from the current
> > > proposed WG charter:
> > >
> > > * the eBPF bindings for the ELF executable file format,
> > >
> > > * the platform support ABI, including calling convention, linker
> > > requirements, and relocations,
> > >
> > > As far as I know (please correct me if I'm wrong), there isn't really a precedence
> > > for standardizing ABIs like this. For example, x86 calling conventions are not
> > > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> > > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> > > standards extensions do not exist for psABI ELF extensions for various
> > > architectures either.
> > >
> > > While it may be that we do end up needing to standardize these ABIs for BPF,
> > > I'm beginning to think that we should just remove them from the current WG
> > > charter, and consider standardizing them at a later time if it's clear that it's
> > > actually necessary. I think this is especially true given that we don't seem to be
> > > getting any closer to having consensus, and that we're very short on time given
> > > that Erik is going to be proposing the charter to the rest of the ADs in just two
> > > days on 5/25.
> > >
> > > Thanks,
> > > David
> >
> > I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
> > llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
> > Linux and Windows. We don't want Windows to diverge.
>
> Be that as it may, as I said before, to my knowledge there's no
> precedence at all for standardizing ABI like this. Is there a reason
> that you think Windows would diverge if we didn't standardize the ABI?
>
> I realize that I'm essentially saying, "Hey, pretend there's a standard
> and don't diverge", but if that's what the entire rest of the industry
> has done up until this point with all other psABIs, then it seems like a
> reasonable expectation.
>
> > As such, I feel strongly that it is a requirement to be standardized right away.
>
> I have to respectfully disagree. I think there are much bigger fish to
> fry, such as standardizing the ISA. Unless we really have a good reason
> for diverging from industry norms, standardizing on ABI now feels to me
> like we're putting the cart before the horse.
Hi Dave et al,
FYI, I just sent out a GitHub PR to remove these lines from the proposed
WG charter: https://github.com/ekline/bpf/pull/5/files. I thought it was
prudent to go ahead and open the PR now given how close we are to the
5/25 meeting, and that we don't seem to be any closer to getting
consensus here.
We can (and should) continue the discussion here, but my two cents is
that unless there's a strong reason to keep ABI standardization within
scope of the WG, that it makes sense to remove these bullets.
That said, if the discussion dies down and/or doesn't continue, IMHO it
would be prudent to merge the PR. I don't think our default position
should be to deviate from well-established industry-wide precedence,
with the onus being on those advocating for following industry norms to
prove that we don't need to discuss it. Again, I may be missing some
important context here, so apologies if that's the case.
Thanks,
David
> Just to be very clear: I could be totally wrong here, and it could be
> very important to deviate from industry norms and standardize ABI as
> part of the initial WG charter. However, IMHO, a positive claim like
> that needs to come with clear substantiation. The reality is that
> deviating from industry norms and standardizing on ABI will have its own
> costs and consequences.
>
> > Hence I would not want this removed from the charter unless there's an effort
> > to do it somewhere else right away, which would seem to increase the coordination
> > burden.
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 19:08 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 19:08 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, bpf@ietf.org, bpf, Erik Kline,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
On Tue, May 23, 2023 at 12:15:35PM -0500, David Vernet wrote:
> On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
> > > -----Original Message-----
> > > From: David Vernet <void@manifault.com>
> > > Sent: Tuesday, May 23, 2023 9:32 AM
> > > To: Dave Thaler <dthaler@microsoft.com>
> > > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> > > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> > > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> > > Alexei Starovoitov <ast@kernel.org>
> > > Subject: Re: [Bpf] IETF BPF working group draft charter
> > >
> > > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > > > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > > > powerpc architectures, along with their variants, handle their ELF
> > > > > extensions and psABI, ensures interoperability good enough for the
> > > problem at hand, but ok.
> > > > > I'm definitely not an expert in these matters.
> > > >
> > > > I am not familiar enough with those to make any comment about that.
> > >
> > > Hi Dave,
> > >
> > > Taking a step back here, perhaps we need to think about all of this more
> > > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> > > opinion this would include, at a minimum, the following items from the current
> > > proposed WG charter:
> > >
> > > * the eBPF bindings for the ELF executable file format,
> > >
> > > * the platform support ABI, including calling convention, linker
> > > requirements, and relocations,
> > >
> > > As far as I know (please correct me if I'm wrong), there isn't really a precedence
> > > for standardizing ABIs like this. For example, x86 calling conventions are not
> > > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> > > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> > > standards extensions do not exist for psABI ELF extensions for various
> > > architectures either.
> > >
> > > While it may be that we do end up needing to standardize these ABIs for BPF,
> > > I'm beginning to think that we should just remove them from the current WG
> > > charter, and consider standardizing them at a later time if it's clear that it's
> > > actually necessary. I think this is especially true given that we don't seem to be
> > > getting any closer to having consensus, and that we're very short on time given
> > > that Erik is going to be proposing the charter to the rest of the ADs in just two
> > > days on 5/25.
> > >
> > > Thanks,
> > > David
> >
> > I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
> > llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
> > Linux and Windows. We don't want Windows to diverge.
>
> Be that as it may, as I said before, to my knowledge there's no
> precedence at all for standardizing ABI like this. Is there a reason
> that you think Windows would diverge if we didn't standardize the ABI?
>
> I realize that I'm essentially saying, "Hey, pretend there's a standard
> and don't diverge", but if that's what the entire rest of the industry
> has done up until this point with all other psABIs, then it seems like a
> reasonable expectation.
>
> > As such, I feel strongly that it is a requirement to be standardized right away.
>
> I have to respectfully disagree. I think there are much bigger fish to
> fry, such as standardizing the ISA. Unless we really have a good reason
> for diverging from industry norms, standardizing on ABI now feels to me
> like we're putting the cart before the horse.
Hi Dave et al,
FYI, I just sent out a GitHub PR to remove these lines from the proposed
WG charter: https://github.com/ekline/bpf/pull/5/files. I thought it was
prudent to go ahead and open the PR now given how close we are to the
5/25 meeting, and that we don't seem to be any closer to getting
consensus here.
We can (and should) continue the discussion here, but my two cents is
that unless there's a strong reason to keep ABI standardization within
scope of the WG, that it makes sense to remove these bullets.
That said, if the discussion dies down and/or doesn't continue, IMHO it
would be prudent to merge the PR. I don't think our default position
should be to deviate from well-established industry-wide precedence,
with the onus being on those advocating for following industry norms to
prove that we don't need to discuss it. Again, I may be missing some
important context here, so apologies if that's the case.
Thanks,
David
> Just to be very clear: I could be totally wrong here, and it could be
> very important to deviate from industry norms and standardize ABI as
> part of the initial WG charter. However, IMHO, a positive claim like
> that needs to come with clear substantiation. The reality is that
> deviating from industry norms and standardizing on ABI will have its own
> costs and consequences.
>
> > Hence I would not want this removed from the charter unless there's an effort
> > to do it somewhere else right away, which would seem to increase the coordination
> > burden.
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 19:42 ` Erik Kline
0 siblings, 0 replies; 59+ messages in thread
From: Erik Kline @ 2023-05-23 19:42 UTC (permalink / raw)
To: David Vernet
Cc: Dave Thaler, Jose E. Marchesi, bpf@ietf.org, bpf,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
how about if we pull ABI but leave ELF?
On Tue, May 23, 2023 at 12:08 PM David Vernet <void@manifault.com> wrote:
>
> On Tue, May 23, 2023 at 12:15:35PM -0500, David Vernet wrote:
> > On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
> > > > -----Original Message-----
> > > > From: David Vernet <void@manifault.com>
> > > > Sent: Tuesday, May 23, 2023 9:32 AM
> > > > To: Dave Thaler <dthaler@microsoft.com>
> > > > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> > > > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> > > > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> > > > Alexei Starovoitov <ast@kernel.org>
> > > > Subject: Re: [Bpf] IETF BPF working group draft charter
> > > >
> > > > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > > > > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > > > > powerpc architectures, along with their variants, handle their ELF
> > > > > > extensions and psABI, ensures interoperability good enough for the
> > > > problem at hand, but ok.
> > > > > > I'm definitely not an expert in these matters.
> > > > >
> > > > > I am not familiar enough with those to make any comment about that.
> > > >
> > > > Hi Dave,
> > > >
> > > > Taking a step back here, perhaps we need to think about all of this more
> > > > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> > > > opinion this would include, at a minimum, the following items from the current
> > > > proposed WG charter:
> > > >
> > > > * the eBPF bindings for the ELF executable file format,
> > > >
> > > > * the platform support ABI, including calling convention, linker
> > > > requirements, and relocations,
> > > >
> > > > As far as I know (please correct me if I'm wrong), there isn't really a precedence
> > > > for standardizing ABIs like this. For example, x86 calling conventions are not
> > > > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> > > > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> > > > standards extensions do not exist for psABI ELF extensions for various
> > > > architectures either.
> > > >
> > > > While it may be that we do end up needing to standardize these ABIs for BPF,
> > > > I'm beginning to think that we should just remove them from the current WG
> > > > charter, and consider standardizing them at a later time if it's clear that it's
> > > > actually necessary. I think this is especially true given that we don't seem to be
> > > > getting any closer to having consensus, and that we're very short on time given
> > > > that Erik is going to be proposing the charter to the rest of the ADs in just two
> > > > days on 5/25.
> > > >
> > > > Thanks,
> > > > David
> > >
> > > I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
> > > llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
> > > Linux and Windows. We don't want Windows to diverge.
> >
> > Be that as it may, as I said before, to my knowledge there's no
> > precedence at all for standardizing ABI like this. Is there a reason
> > that you think Windows would diverge if we didn't standardize the ABI?
> >
> > I realize that I'm essentially saying, "Hey, pretend there's a standard
> > and don't diverge", but if that's what the entire rest of the industry
> > has done up until this point with all other psABIs, then it seems like a
> > reasonable expectation.
> >
> > > As such, I feel strongly that it is a requirement to be standardized right away.
> >
> > I have to respectfully disagree. I think there are much bigger fish to
> > fry, such as standardizing the ISA. Unless we really have a good reason
> > for diverging from industry norms, standardizing on ABI now feels to me
> > like we're putting the cart before the horse.
>
> Hi Dave et al,
>
> FYI, I just sent out a GitHub PR to remove these lines from the proposed
> WG charter: https://github.com/ekline/bpf/pull/5/files. I thought it was
> prudent to go ahead and open the PR now given how close we are to the
> 5/25 meeting, and that we don't seem to be any closer to getting
> consensus here.
>
> We can (and should) continue the discussion here, but my two cents is
> that unless there's a strong reason to keep ABI standardization within
> scope of the WG, that it makes sense to remove these bullets.
>
> That said, if the discussion dies down and/or doesn't continue, IMHO it
> would be prudent to merge the PR. I don't think our default position
> should be to deviate from well-established industry-wide precedence,
> with the onus being on those advocating for following industry norms to
> prove that we don't need to discuss it. Again, I may be missing some
> important context here, so apologies if that's the case.
>
> Thanks,
> David
>
> > Just to be very clear: I could be totally wrong here, and it could be
> > very important to deviate from industry norms and standardize ABI as
> > part of the initial WG charter. However, IMHO, a positive claim like
> > that needs to come with clear substantiation. The reality is that
> > deviating from industry norms and standardizing on ABI will have its own
> > costs and consequences.
> >
> > > Hence I would not want this removed from the charter unless there's an effort
> > > to do it somewhere else right away, which would seem to increase the coordination
> > > burden.
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 19:42 ` Erik Kline
0 siblings, 0 replies; 59+ messages in thread
From: Erik Kline @ 2023-05-23 19:42 UTC (permalink / raw)
To: David Vernet
Cc: Dave Thaler, Jose E. Marchesi, bpf@ietf.org, bpf,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
how about if we pull ABI but leave ELF?
On Tue, May 23, 2023 at 12:08 PM David Vernet <void@manifault.com> wrote:
>
> On Tue, May 23, 2023 at 12:15:35PM -0500, David Vernet wrote:
> > On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
> > > > -----Original Message-----
> > > > From: David Vernet <void@manifault.com>
> > > > Sent: Tuesday, May 23, 2023 9:32 AM
> > > > To: Dave Thaler <dthaler@microsoft.com>
> > > > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
> > > > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
> > > > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
> > > > Alexei Starovoitov <ast@kernel.org>
> > > > Subject: Re: [Bpf] IETF BPF working group draft charter
> > > >
> > > > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
> > > > > Jose E. Marchesi <jemarch@gnu.org> wrote:
> > > > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
> > > > > > powerpc architectures, along with their variants, handle their ELF
> > > > > > extensions and psABI, ensures interoperability good enough for the
> > > > problem at hand, but ok.
> > > > > > I'm definitely not an expert in these matters.
> > > > >
> > > > > I am not familiar enough with those to make any comment about that.
> > > >
> > > > Hi Dave,
> > > >
> > > > Taking a step back here, perhaps we need to think about all of this more
> > > > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
> > > > opinion this would include, at a minimum, the following items from the current
> > > > proposed WG charter:
> > > >
> > > > * the eBPF bindings for the ELF executable file format,
> > > >
> > > > * the platform support ABI, including calling convention, linker
> > > > requirements, and relocations,
> > > >
> > > > As far as I know (please correct me if I'm wrong), there isn't really a precedence
> > > > for standardizing ABIs like this. For example, x86 calling conventions are not
> > > > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
> > > > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
> > > > standards extensions do not exist for psABI ELF extensions for various
> > > > architectures either.
> > > >
> > > > While it may be that we do end up needing to standardize these ABIs for BPF,
> > > > I'm beginning to think that we should just remove them from the current WG
> > > > charter, and consider standardizing them at a later time if it's clear that it's
> > > > actually necessary. I think this is especially true given that we don't seem to be
> > > > getting any closer to having consensus, and that we're very short on time given
> > > > that Erik is going to be proposing the charter to the rest of the ADs in just two
> > > > days on 5/25.
> > > >
> > > > Thanks,
> > > > David
> > >
> > > I can tell you it's very important to those who work on the ebpf-for-windows project that the ELF format is common between Linux and Windows so that tools like
> > > llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
> > > Linux and Windows. We don't want Windows to diverge.
> >
> > Be that as it may, as I said before, to my knowledge there's no
> > precedence at all for standardizing ABI like this. Is there a reason
> > that you think Windows would diverge if we didn't standardize the ABI?
> >
> > I realize that I'm essentially saying, "Hey, pretend there's a standard
> > and don't diverge", but if that's what the entire rest of the industry
> > has done up until this point with all other psABIs, then it seems like a
> > reasonable expectation.
> >
> > > As such, I feel strongly that it is a requirement to be standardized right away.
> >
> > I have to respectfully disagree. I think there are much bigger fish to
> > fry, such as standardizing the ISA. Unless we really have a good reason
> > for diverging from industry norms, standardizing on ABI now feels to me
> > like we're putting the cart before the horse.
>
> Hi Dave et al,
>
> FYI, I just sent out a GitHub PR to remove these lines from the proposed
> WG charter: https://github.com/ekline/bpf/pull/5/files. I thought it was
> prudent to go ahead and open the PR now given how close we are to the
> 5/25 meeting, and that we don't seem to be any closer to getting
> consensus here.
>
> We can (and should) continue the discussion here, but my two cents is
> that unless there's a strong reason to keep ABI standardization within
> scope of the WG, that it makes sense to remove these bullets.
>
> That said, if the discussion dies down and/or doesn't continue, IMHO it
> would be prudent to merge the PR. I don't think our default position
> should be to deviate from well-established industry-wide precedence,
> with the onus being on those advocating for following industry norms to
> prove that we don't need to discuss it. Again, I may be missing some
> important context here, so apologies if that's the case.
>
> Thanks,
> David
>
> > Just to be very clear: I could be totally wrong here, and it could be
> > very important to deviate from industry norms and standardize ABI as
> > part of the initial WG charter. However, IMHO, a positive claim like
> > that needs to come with clear substantiation. The reality is that
> > deviating from industry norms and standardizing on ABI will have its own
> > costs and consequences.
> >
> > > Hence I would not want this removed from the charter unless there's an effort
> > > to do it somewhere else right away, which would seem to increase the coordination
> > > burden.
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 19:47 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-23 19:47 UTC (permalink / raw)
To: Erik Kline
Cc: David Vernet, Dave Thaler, bpf@ietf.org, bpf,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
> how about if we pull ABI but leave ELF?
The ELF architecture-specific configuration and extensions are
traditionally part of the psABI. Chapter 4 Object Files.
>
> On Tue, May 23, 2023 at 12:08 PM David Vernet <void@manifault.com> wrote:
>>
>> On Tue, May 23, 2023 at 12:15:35PM -0500, David Vernet wrote:
>> > On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
>> > > > -----Original Message-----
>> > > > From: David Vernet <void@manifault.com>
>> > > > Sent: Tuesday, May 23, 2023 9:32 AM
>> > > > To: Dave Thaler <dthaler@microsoft.com>
>> > > > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
>> > > > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
>> > > > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
>> > > > Alexei Starovoitov <ast@kernel.org>
>> > > > Subject: Re: [Bpf] IETF BPF working group draft charter
>> > > >
>> > > > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
>> > > > > Jose E. Marchesi <jemarch@gnu.org> wrote:
>> > > > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
>> > > > > > powerpc architectures, along with their variants, handle their ELF
>> > > > > > extensions and psABI, ensures interoperability good enough for the
>> > > > problem at hand, but ok.
>> > > > > > I'm definitely not an expert in these matters.
>> > > > >
>> > > > > I am not familiar enough with those to make any comment about that.
>> > > >
>> > > > Hi Dave,
>> > > >
>> > > > Taking a step back here, perhaps we need to think about all of this more
>> > > > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
>> > > > opinion this would include, at a minimum, the following items from the current
>> > > > proposed WG charter:
>> > > >
>> > > > * the eBPF bindings for the ELF executable file format,
>> > > >
>> > > > * the platform support ABI, including calling convention, linker
>> > > > requirements, and relocations,
>> > > >
>> > > > As far as I know (please correct me if I'm wrong), there isn't really a precedence
>> > > > for standardizing ABIs like this. For example, x86 calling conventions are not
>> > > > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
>> > > > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
>> > > > standards extensions do not exist for psABI ELF extensions for various
>> > > > architectures either.
>> > > >
>> > > > While it may be that we do end up needing to standardize these ABIs for BPF,
>> > > > I'm beginning to think that we should just remove them from the current WG
>> > > > charter, and consider standardizing them at a later time if it's clear that it's
>> > > > actually necessary. I think this is especially true given that we don't seem to be
>> > > > getting any closer to having consensus, and that we're very short on time given
>> > > > that Erik is going to be proposing the charter to the rest of the ADs in just two
>> > > > days on 5/25.
>> > > >
>> > > > Thanks,
>> > > > David
>> > >
>> > > I can tell you it's very important to those who work on the
>> > > ebpf-for-windows project that the ELF format is common between
>> > > Linux and Windows so that tools like
>> > > llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
>> > > Linux and Windows. We don't want Windows to diverge.
>> >
>> > Be that as it may, as I said before, to my knowledge there's no
>> > precedence at all for standardizing ABI like this. Is there a reason
>> > that you think Windows would diverge if we didn't standardize the ABI?
>> >
>> > I realize that I'm essentially saying, "Hey, pretend there's a standard
>> > and don't diverge", but if that's what the entire rest of the industry
>> > has done up until this point with all other psABIs, then it seems like a
>> > reasonable expectation.
>> >
>> > > As such, I feel strongly that it is a requirement to be standardized right away.
>> >
>> > I have to respectfully disagree. I think there are much bigger fish to
>> > fry, such as standardizing the ISA. Unless we really have a good reason
>> > for diverging from industry norms, standardizing on ABI now feels to me
>> > like we're putting the cart before the horse.
>>
>> Hi Dave et al,
>>
>> FYI, I just sent out a GitHub PR to remove these lines from the proposed
>> WG charter: https://github.com/ekline/bpf/pull/5/files. I thought it was
>> prudent to go ahead and open the PR now given how close we are to the
>> 5/25 meeting, and that we don't seem to be any closer to getting
>> consensus here.
>>
>> We can (and should) continue the discussion here, but my two cents is
>> that unless there's a strong reason to keep ABI standardization within
>> scope of the WG, that it makes sense to remove these bullets.
>>
>> That said, if the discussion dies down and/or doesn't continue, IMHO it
>> would be prudent to merge the PR. I don't think our default position
>> should be to deviate from well-established industry-wide precedence,
>> with the onus being on those advocating for following industry norms to
>> prove that we don't need to discuss it. Again, I may be missing some
>> important context here, so apologies if that's the case.
>>
>> Thanks,
>> David
>>
>> > Just to be very clear: I could be totally wrong here, and it could be
>> > very important to deviate from industry norms and standardize ABI as
>> > part of the initial WG charter. However, IMHO, a positive claim like
>> > that needs to come with clear substantiation. The reality is that
>> > deviating from industry norms and standardizing on ABI will have its own
>> > costs and consequences.
>> >
>> > > Hence I would not want this removed from the charter unless there's an effort
>> > > to do it somewhere else right away, which would seem to increase the coordination
>> > > burden.
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 19:47 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-23 19:47 UTC (permalink / raw)
To: Erik Kline
Cc: David Vernet, Dave Thaler, bpf@ietf.org, bpf,
Suresh Krishnan (sureshk), Christoph Hellwig, Alexei Starovoitov
> how about if we pull ABI but leave ELF?
The ELF architecture-specific configuration and extensions are
traditionally part of the psABI. Chapter 4 Object Files.
>
> On Tue, May 23, 2023 at 12:08 PM David Vernet <void@manifault.com> wrote:
>>
>> On Tue, May 23, 2023 at 12:15:35PM -0500, David Vernet wrote:
>> > On Tue, May 23, 2023 at 04:50:42PM +0000, Dave Thaler wrote:
>> > > > -----Original Message-----
>> > > > From: David Vernet <void@manifault.com>
>> > > > Sent: Tuesday, May 23, 2023 9:32 AM
>> > > > To: Dave Thaler <dthaler@microsoft.com>
>> > > > Cc: Jose E. Marchesi <jemarch@gnu.org>; bpf@ietf.org; bpf
>> > > > <bpf@vger.kernel.org>; Erik Kline <ek.ietf@gmail.com>; Suresh Krishnan
>> > > > (sureshk) <sureshk@cisco.com>; Christoph Hellwig <hch@infradead.org>;
>> > > > Alexei Starovoitov <ast@kernel.org>
>> > > > Subject: Re: [Bpf] IETF BPF working group draft charter
>> > > >
>> > > > On Thu, May 18, 2023 at 07:42:11PM +0000, Dave Thaler wrote:
>> > > > > Jose E. Marchesi <jemarch@gnu.org> wrote:
>> > > > > > I would think that the way the x86_64, aarch64, risc-v, sparc, mips,
>> > > > > > powerpc architectures, along with their variants, handle their ELF
>> > > > > > extensions and psABI, ensures interoperability good enough for the
>> > > > problem at hand, but ok.
>> > > > > > I'm definitely not an expert in these matters.
>> > > > >
>> > > > > I am not familiar enough with those to make any comment about that.
>> > > >
>> > > > Hi Dave,
>> > > >
>> > > > Taking a step back here, perhaps we need to think about all of this more
>> > > > generically as "ABI", rather than ELF "extensions", "bindings", etc. In my
>> > > > opinion this would include, at a minimum, the following items from the current
>> > > > proposed WG charter:
>> > > >
>> > > > * the eBPF bindings for the ELF executable file format,
>> > > >
>> > > > * the platform support ABI, including calling convention, linker
>> > > > requirements, and relocations,
>> > > >
>> > > > As far as I know (please correct me if I'm wrong), there isn't really a precedence
>> > > > for standardizing ABIs like this. For example, x86 calling conventions are not
>> > > > standardized. Solaris, Linux, FreeBSD, macOS, etc all follow the System V
>> > > > AMD64 ABI, but Microsoft of course does not. As Jose pointed out, such
>> > > > standards extensions do not exist for psABI ELF extensions for various
>> > > > architectures either.
>> > > >
>> > > > While it may be that we do end up needing to standardize these ABIs for BPF,
>> > > > I'm beginning to think that we should just remove them from the current WG
>> > > > charter, and consider standardizing them at a later time if it's clear that it's
>> > > > actually necessary. I think this is especially true given that we don't seem to be
>> > > > getting any closer to having consensus, and that we're very short on time given
>> > > > that Erik is going to be proposing the charter to the rest of the ADs in just two
>> > > > days on 5/25.
>> > > >
>> > > > Thanks,
>> > > > David
>> > >
>> > > I can tell you it's very important to those who work on the
>> > > ebpf-for-windows project that the ELF format is common between
>> > > Linux and Windows so that tools like
>> > > llvm-objdump and bpftool and other BPF-specific ELF parsing tools work for both
>> > > Linux and Windows. We don't want Windows to diverge.
>> >
>> > Be that as it may, as I said before, to my knowledge there's no
>> > precedence at all for standardizing ABI like this. Is there a reason
>> > that you think Windows would diverge if we didn't standardize the ABI?
>> >
>> > I realize that I'm essentially saying, "Hey, pretend there's a standard
>> > and don't diverge", but if that's what the entire rest of the industry
>> > has done up until this point with all other psABIs, then it seems like a
>> > reasonable expectation.
>> >
>> > > As such, I feel strongly that it is a requirement to be standardized right away.
>> >
>> > I have to respectfully disagree. I think there are much bigger fish to
>> > fry, such as standardizing the ISA. Unless we really have a good reason
>> > for diverging from industry norms, standardizing on ABI now feels to me
>> > like we're putting the cart before the horse.
>>
>> Hi Dave et al,
>>
>> FYI, I just sent out a GitHub PR to remove these lines from the proposed
>> WG charter: https://github.com/ekline/bpf/pull/5/files. I thought it was
>> prudent to go ahead and open the PR now given how close we are to the
>> 5/25 meeting, and that we don't seem to be any closer to getting
>> consensus here.
>>
>> We can (and should) continue the discussion here, but my two cents is
>> that unless there's a strong reason to keep ABI standardization within
>> scope of the WG, that it makes sense to remove these bullets.
>>
>> That said, if the discussion dies down and/or doesn't continue, IMHO it
>> would be prudent to merge the PR. I don't think our default position
>> should be to deviate from well-established industry-wide precedence,
>> with the onus being on those advocating for following industry norms to
>> prove that we don't need to discuss it. Again, I may be missing some
>> important context here, so apologies if that's the case.
>>
>> Thanks,
>> David
>>
>> > Just to be very clear: I could be totally wrong here, and it could be
>> > very important to deviate from industry norms and standardize ABI as
>> > part of the initial WG charter. However, IMHO, a positive claim like
>> > that needs to come with clear substantiation. The reality is that
>> > deviating from industry norms and standardizing on ABI will have its own
>> > costs and consequences.
>> >
>> > > Hence I would not want this removed from the charter unless there's an effort
>> > > to do it somewhere else right away, which would seem to increase the coordination
>> > > burden.
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 17:58 ` Michael Richardson
0 siblings, 0 replies; 59+ messages in thread
From: Michael Richardson @ 2023-05-23 17:58 UTC (permalink / raw)
To: bpf@ietf.org, bpf
[-- Attachment #1.1: Type: text/plain, Size: 620 bytes --]
David Vernet <void@manifault.com> wrote:
> As far as I know (please correct me if I'm wrong), there isn't really a
> precedence for standardizing ABIs like this. For example, x86 calling
All of the eBPF work seems unprecedented.
I don't see having this in the charter is a problem.
We may fail to get consensus on it, and not make a milestone, but I don't see
a reason not to be allowed to talk about this.
(and maybe in the end, it's a no-op)
--
Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]
[-- Attachment #2: Type: text/plain, Size: 76 bytes --]
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 17:58 ` Michael Richardson
0 siblings, 0 replies; 59+ messages in thread
From: Michael Richardson @ 2023-05-23 17:58 UTC (permalink / raw)
To: bpf@ietf.org, bpf
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
David Vernet <void@manifault.com> wrote:
> As far as I know (please correct me if I'm wrong), there isn't really a
> precedence for standardizing ABIs like this. For example, x86 calling
All of the eBPF work seems unprecedented.
I don't see having this in the charter is a problem.
We may fail to get consensus on it, and not make a milestone, but I don't see
a reason not to be allowed to talk about this.
(and maybe in the end, it's a no-op)
--
Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]
^ permalink raw reply [flat|nested] 59+ messages in thread* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 18:25 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-23 18:25 UTC (permalink / raw)
To: Michael Richardson, bpf@ietf.org, bpf
One possibility which is unusual but has been done in some cases is
to have an Informational RFC for something that is later standardized
by another body. (RFC 3678 is one of a couple of such examples.)
Dave
> -----Original Message-----
> From: Bpf <bpf-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Tuesday, May 23, 2023 10:58 AM
> To: bpf@ietf.org; bpf <bpf@vger.kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
>
> David Vernet <void@manifault.com> wrote:
> > As far as I know (please correct me if I'm wrong), there isn't really a
> > precedence for standardizing ABIs like this. For example, x86 calling
>
> All of the eBPF work seems unprecedented.
> I don't see having this in the charter is a problem.
>
> We may fail to get consensus on it, and not make a milestone, but I don't see a
> reason not to be allowed to talk about this.
> (and maybe in the end, it's a no-op)
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 18:25 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-23 18:25 UTC (permalink / raw)
To: Michael Richardson, bpf@ietf.org, bpf
One possibility which is unusual but has been done in some cases is
to have an Informational RFC for something that is later standardized
by another body. (RFC 3678 is one of a couple of such examples.)
Dave
> -----Original Message-----
> From: Bpf <bpf-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Tuesday, May 23, 2023 10:58 AM
> To: bpf@ietf.org; bpf <bpf@vger.kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
>
> David Vernet <void@manifault.com> wrote:
> > As far as I know (please correct me if I'm wrong), there isn't really a
> > precedence for standardizing ABIs like this. For example, x86 calling
>
> All of the eBPF work seems unprecedented.
> I don't see having this in the charter is a problem.
>
> We may fail to get consensus on it, and not make a milestone, but I don't see a
> reason not to be allowed to talk about this.
> (and maybe in the end, it's a no-op)
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 20:28 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 20:28 UTC (permalink / raw)
To: Michael Richardson
Cc: bpf@ietf.org, bpf, Alexei Starovoitov, Jose E. Marchesi,
Erik Kline, Suresh Krishnan (sureshk), Christoph Hellwig,
Dave Thaler
On Tue, May 23, 2023 at 01:58:18PM -0400, Michael Richardson wrote:
>
> David Vernet <void@manifault.com> wrote:
> > As far as I know (please correct me if I'm wrong), there isn't really a
> > precedence for standardizing ABIs like this. For example, x86 calling
>
> All of the eBPF work seems unprecedented.
> I don't see having this in the charter is a problem.
>
> We may fail to get consensus on it, and not make a milestone, but I don't see
> a reason not to be allowed to talk about this.
> (and maybe in the end, it's a no-op)
Hi Michael,
So apologies in advance if my lack of experience with IETF proceedings
is glaringly obvious, and I'd appreciate clarification in any situation
in which I'm mistaken.
My understanding based on the conversations that I've had thus far is
that part of the goal of arriving at the finalized WG charter is to
determine what's in scope and out of scope. It's a bit of a murky
proposition because some things that we think _could_ be in scope, such
as in this case topics related to psABI, may not end up having a
document if we can't get consensus. In other words, being in the WG
charter doesn't imply that something is in-scope and will have a
document written, but _not_ being in the charter does preclude it from
being discussed in this iteration of the WG because of this line:
> The working group shall not adopt new work until these
> documents have progressed to working group last call.
The implication of this is that it's not necessarily a problem to have
some false-positives in terms of what we cover, but it can be
problematic if we leave out something important because we'll have to
cover all of the other topics first. I'd imagine this would tend to make
the default behavior for deciding scope in WG charters to be permissive
rather than dissmive, which makes sense to me.
Assuming I haven't already gone off the rails in terms of my
understanding, let me try to clarify why despite all that, I still think
it's warranted for us to remove psABI as part of the scope of the WG.
There are really two main reasons:
1. As is hopefully clear at this point, there is a wide and historical
industry precedence for not standardizing on psABI. For example, to
my knowledge, RISC-V [0] develops and ratifies the RISC-V ISA through
the RISC-V International Technical Working Groups, but there is no
such ratified standard or specification for RISC-V calling
conventions (the operative word of course being "convention"). The
same is true (to my knowledge) of _all_ psABI ELF extensions, as Jose
pointed out earlier in the conversation.
[0]: https://riscv.org/technical/specifications/
With all that said, unless there's more context behind why we think we
need to standardize psABI which hasn't yet been brought forward, I
don't see any way we'd achieve consensus when we discuss it in the
WG. And the reason I specifically think that's the case for ABI (ELF
or otherwise) is that there's such a well-established precedence
already for not standardizing it. I guess it's true that there's no
harm in including it and discussing it, but as things currently
stand, it also doesn't seem very productive to include it if there's
already (IMHO) reasonably clear evidence that it's out of scope. To
go back to my claim made in another email, I think the onus is on the
folks who think it's in scope to explain why, rather than the folks
who think we should follow industry precedence to justify that.
2. Assuming that I'm wrong, and ABI / ELF are in scope for
standardization, we would still have to do a lot of premliminary
work to determine that. For example, we may end up wanting to
standardize that maps are put into .maps sections in an ELF file, but
that would only make sense if we created a document standardizing
cross-platform map types. The same holds true for cross-platform
program types, etc. The dependency DAG for discussing ELF has a depth
of at least 2, and given that it's as-yet unclear whether ELF / psABI
is an appropriate topic for standardization in the first place, it
really feels to me like leaving it out of the WG is the right move.
Thanks,
David
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-23 20:28 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-23 20:28 UTC (permalink / raw)
To: Michael Richardson
Cc: bpf@ietf.org, bpf, Alexei Starovoitov, Jose E. Marchesi,
Erik Kline, Suresh Krishnan (sureshk), Christoph Hellwig,
Dave Thaler
On Tue, May 23, 2023 at 01:58:18PM -0400, Michael Richardson wrote:
>
> David Vernet <void@manifault.com> wrote:
> > As far as I know (please correct me if I'm wrong), there isn't really a
> > precedence for standardizing ABIs like this. For example, x86 calling
>
> All of the eBPF work seems unprecedented.
> I don't see having this in the charter is a problem.
>
> We may fail to get consensus on it, and not make a milestone, but I don't see
> a reason not to be allowed to talk about this.
> (and maybe in the end, it's a no-op)
Hi Michael,
So apologies in advance if my lack of experience with IETF proceedings
is glaringly obvious, and I'd appreciate clarification in any situation
in which I'm mistaken.
My understanding based on the conversations that I've had thus far is
that part of the goal of arriving at the finalized WG charter is to
determine what's in scope and out of scope. It's a bit of a murky
proposition because some things that we think _could_ be in scope, such
as in this case topics related to psABI, may not end up having a
document if we can't get consensus. In other words, being in the WG
charter doesn't imply that something is in-scope and will have a
document written, but _not_ being in the charter does preclude it from
being discussed in this iteration of the WG because of this line:
> The working group shall not adopt new work until these
> documents have progressed to working group last call.
The implication of this is that it's not necessarily a problem to have
some false-positives in terms of what we cover, but it can be
problematic if we leave out something important because we'll have to
cover all of the other topics first. I'd imagine this would tend to make
the default behavior for deciding scope in WG charters to be permissive
rather than dissmive, which makes sense to me.
Assuming I haven't already gone off the rails in terms of my
understanding, let me try to clarify why despite all that, I still think
it's warranted for us to remove psABI as part of the scope of the WG.
There are really two main reasons:
1. As is hopefully clear at this point, there is a wide and historical
industry precedence for not standardizing on psABI. For example, to
my knowledge, RISC-V [0] develops and ratifies the RISC-V ISA through
the RISC-V International Technical Working Groups, but there is no
such ratified standard or specification for RISC-V calling
conventions (the operative word of course being "convention"). The
same is true (to my knowledge) of _all_ psABI ELF extensions, as Jose
pointed out earlier in the conversation.
[0]: https://riscv.org/technical/specifications/
With all that said, unless there's more context behind why we think we
need to standardize psABI which hasn't yet been brought forward, I
don't see any way we'd achieve consensus when we discuss it in the
WG. And the reason I specifically think that's the case for ABI (ELF
or otherwise) is that there's such a well-established precedence
already for not standardizing it. I guess it's true that there's no
harm in including it and discussing it, but as things currently
stand, it also doesn't seem very productive to include it if there's
already (IMHO) reasonably clear evidence that it's out of scope. To
go back to my claim made in another email, I think the onus is on the
folks who think it's in scope to explain why, rather than the folks
who think we should follow industry precedence to justify that.
2. Assuming that I'm wrong, and ABI / ELF are in scope for
standardization, we would still have to do a lot of premliminary
work to determine that. For example, we may end up wanting to
standardize that maps are put into .maps sections in an ELF file, but
that would only make sense if we created a document standardizing
cross-platform map types. The same holds true for cross-platform
program types, etc. The dependency DAG for discussing ELF has a depth
of at least 2, and given that it's as-yet unclear whether ELF / psABI
is an appropriate topic for standardization in the first place, it
really feels to me like leaving it out of the WG is the right move.
Thanks,
David
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
2023-05-23 20:28 ` David Vernet
(?)
@ 2023-05-24 20:38 ` Suresh Krishnan
2023-05-24 21:06 ` Jose E. Marchesi
-1 siblings, 1 reply; 59+ messages in thread
From: Suresh Krishnan @ 2023-05-24 20:38 UTC (permalink / raw)
To: David Vernet
Cc: Michael Richardson, bpf@ietf.org, bpf, Alexei Starovoitov,
Jose E. Marchesi, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig, Dave Thaler
[-- Attachment #1.1: Type: text/plain, Size: 6025 bytes --]
Hi David,
I just want to provide a quick clarification from the IETF side regarding categories of RFCs. Not all the RFCs we produce are standards. On a broad level we have standards track and informational documents (among others; more details in RFC2026). I do believe there is value in *documenting* some of the items that belong in an ABI such as the calling convention (similar to what is in Section 2 of the ISA draft). Similarly, there is value in documenting conventions and guidelines for creating portable binaries if we believe that is a useful goal, even though there will be a lot of programs that will not be portable (e.g. using cgroups). I would not expect these to be Standards track documents but rather Informational specifications to help implementers. If that sounds reasonable we can keep the text in the charter (with some minor rewording) and work on categorizing potential deliverables by Document Status (as would anyway be necessitated by Éric Vyncke’s BLOCK).
Regards
Suresh
> On May 23, 2023, at 4:28 PM, David Vernet <void@manifault.com> wrote:
>
> On Tue, May 23, 2023 at 01:58:18PM -0400, Michael Richardson wrote:
>>
>> David Vernet <void@manifault.com <mailto:void@manifault.com>> wrote:
>>> As far as I know (please correct me if I'm wrong), there isn't really a
>>> precedence for standardizing ABIs like this. For example, x86 calling
>>
>> All of the eBPF work seems unprecedented.
>> I don't see having this in the charter is a problem.
>>
>> We may fail to get consensus on it, and not make a milestone, but I don't see
>> a reason not to be allowed to talk about this.
>> (and maybe in the end, it's a no-op)
>
> Hi Michael,
>
> So apologies in advance if my lack of experience with IETF proceedings
> is glaringly obvious, and I'd appreciate clarification in any situation
> in which I'm mistaken.
>
> My understanding based on the conversations that I've had thus far is
> that part of the goal of arriving at the finalized WG charter is to
> determine what's in scope and out of scope. It's a bit of a murky
> proposition because some things that we think _could_ be in scope, such
> as in this case topics related to psABI, may not end up having a
> document if we can't get consensus. In other words, being in the WG
> charter doesn't imply that something is in-scope and will have a
> document written, but _not_ being in the charter does preclude it from
> being discussed in this iteration of the WG because of this line:
>
>> The working group shall not adopt new work until these
>> documents have progressed to working group last call.
>
> The implication of this is that it's not necessarily a problem to have
> some false-positives in terms of what we cover, but it can be
> problematic if we leave out something important because we'll have to
> cover all of the other topics first. I'd imagine this would tend to make
> the default behavior for deciding scope in WG charters to be permissive
> rather than dissmive, which makes sense to me.
>
> Assuming I haven't already gone off the rails in terms of my
> understanding, let me try to clarify why despite all that, I still think
> it's warranted for us to remove psABI as part of the scope of the WG.
> There are really two main reasons:
>
> 1. As is hopefully clear at this point, there is a wide and historical
> industry precedence for not standardizing on psABI. For example, to
> my knowledge, RISC-V [0] develops and ratifies the RISC-V ISA through
> the RISC-V International Technical Working Groups, but there is no
> such ratified standard or specification for RISC-V calling
> conventions (the operative word of course being "convention"). The
> same is true (to my knowledge) of _all_ psABI ELF extensions, as Jose
> pointed out earlier in the conversation.
>
> [0]: https://riscv.org/technical/specifications/ <https://riscv.org/technical/specifications/>
>
> With all that said, unless there's more context behind why we think we
> need to standardize psABI which hasn't yet been brought forward, I
> don't see any way we'd achieve consensus when we discuss it in the
> WG. And the reason I specifically think that's the case for ABI (ELF
> or otherwise) is that there's such a well-established precedence
> already for not standardizing it. I guess it's true that there's no
> harm in including it and discussing it, but as things currently
> stand, it also doesn't seem very productive to include it if there's
> already (IMHO) reasonably clear evidence that it's out of scope. To
> go back to my claim made in another email, I think the onus is on the
> folks who think it's in scope to explain why, rather than the folks
> who think we should follow industry precedence to justify that.
>
> 2. Assuming that I'm wrong, and ABI / ELF are in scope for
> standardization, we would still have to do a lot of premliminary
> work to determine that. For example, we may end up wanting to
> standardize that maps are put into .maps sections in an ELF file, but
> that would only make sense if we created a document standardizing
> cross-platform map types. The same holds true for cross-platform
> program types, etc. The dependency DAG for discussing ELF has a depth
> of at least 2, and given that it's as-yet unclear whether ELF / psABI
> is an appropriate topic for standardization in the first place, it
> really feels to me like leaving it out of the WG is the right move.
>
> Thanks,
> David
>
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
>> Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>
>
>
>> --
>> Bpf mailing list
>> Bpf@ietf.org
>> https://www.ietf.org/mailman/listinfo/bpf
>
> --
> Bpf mailing list
> Bpf@ietf.org <mailto:Bpf@ietf.org>
> https://www.ietf.org/mailman/listinfo/bpf <https://www.ietf.org/mailman/listinfo/bpf>
[-- Attachment #1.2: Type: text/html, Size: 57560 bytes --]
[-- Attachment #2: Type: text/plain, Size: 76 bytes --]
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-24 21:06 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-24 21:06 UTC (permalink / raw)
To: Suresh Krishnan
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig, Dave Thaler
> Hi David,
> I just want to provide a quick clarification from the IETF side
> regarding categories of RFCs. Not all the RFCs we produce are
> standards. On a broad level we have standards track and informational
> documents (among others; more details in RFC2026). I do believe there
> is value in *documenting* some of the items that belong in an ABI such
> as the calling convention (similar to what is in Section 2 of the ISA
> draft). Similarly, there is value in documenting conventions and
> guidelines for creating portable binaries if we believe that is a
> useful goal, even though there will be a lot of programs that will not
> be portable (e.g. using cgroups). I would not expect these to be
> Standards track documents but rather Informational specifications to
> help implementers. If that sounds reasonable we can keep the text in
> the charter (with some minor rewording) and work on categorizing
> potential deliverables by Document Status (as would anyway be
> necessitated by Éric Vyncke’s BLOCK).
I wonder. Lets suppose the ABI and ELF extensions are maintained and
evolved in the usual way it is done for all other architectures, i.e.
in the kernel git repository or a dedicatd public one, in textual form,
under a free software license, not requiring copyright assignments nor
bureocratic processes to be updated, etc. Could then the WG edit and
publish "snapshots" whenever considered appropriate, and release them as
subsequent versions of an IETF Informational specification, or some
other suitable kind of IETF document?
If something like that would be doable, maybe we could concile the
practicality of the usual approach with the more formal character of an
IETF document?
> Regards
> Suresh
>
>> On May 23, 2023, at 4:28 PM, David Vernet <void@manifault.com> wrote:
>>
>> On Tue, May 23, 2023 at 01:58:18PM -0400, Michael Richardson wrote:
>>>
>>> David Vernet <void@manifault.com <mailto:void@manifault.com>> wrote:
>>>> As far as I know (please correct me if I'm wrong), there isn't really a
>>>> precedence for standardizing ABIs like this. For example, x86 calling
>>>
>>> All of the eBPF work seems unprecedented.
>>> I don't see having this in the charter is a problem.
>>>
>>> We may fail to get consensus on it, and not make a milestone, but I don't see
>>> a reason not to be allowed to talk about this.
>>> (and maybe in the end, it's a no-op)
>>
>> Hi Michael,
>>
>> So apologies in advance if my lack of experience with IETF proceedings
>> is glaringly obvious, and I'd appreciate clarification in any situation
>> in which I'm mistaken.
>>
>> My understanding based on the conversations that I've had thus far is
>> that part of the goal of arriving at the finalized WG charter is to
>> determine what's in scope and out of scope. It's a bit of a murky
>> proposition because some things that we think _could_ be in scope, such
>> as in this case topics related to psABI, may not end up having a
>> document if we can't get consensus. In other words, being in the WG
>> charter doesn't imply that something is in-scope and will have a
>> document written, but _not_ being in the charter does preclude it from
>> being discussed in this iteration of the WG because of this line:
>>
>>> The working group shall not adopt new work until these
>>> documents have progressed to working group last call.
>>
>> The implication of this is that it's not necessarily a problem to have
>> some false-positives in terms of what we cover, but it can be
>> problematic if we leave out something important because we'll have to
>> cover all of the other topics first. I'd imagine this would tend to make
>> the default behavior for deciding scope in WG charters to be permissive
>> rather than dissmive, which makes sense to me.
>>
>> Assuming I haven't already gone off the rails in terms of my
>> understanding, let me try to clarify why despite all that, I still think
>> it's warranted for us to remove psABI as part of the scope of the WG.
>> There are really two main reasons:
>>
>> 1. As is hopefully clear at this point, there is a wide and historical
>> industry precedence for not standardizing on psABI. For example, to
>> my knowledge, RISC-V [0] develops and ratifies the RISC-V ISA through
>> the RISC-V International Technical Working Groups, but there is no
>> such ratified standard or specification for RISC-V calling
>> conventions (the operative word of course being "convention"). The
>> same is true (to my knowledge) of _all_ psABI ELF extensions, as Jose
>> pointed out earlier in the conversation.
>>
>> [0]: https://riscv.org/technical/specifications/ <https://riscv.org/technical/specifications/>
>>
>> With all that said, unless there's more context behind why we think we
>> need to standardize psABI which hasn't yet been brought forward, I
>> don't see any way we'd achieve consensus when we discuss it in the
>> WG. And the reason I specifically think that's the case for ABI (ELF
>> or otherwise) is that there's such a well-established precedence
>> already for not standardizing it. I guess it's true that there's no
>> harm in including it and discussing it, but as things currently
>> stand, it also doesn't seem very productive to include it if there's
>> already (IMHO) reasonably clear evidence that it's out of scope. To
>> go back to my claim made in another email, I think the onus is on the
>> folks who think it's in scope to explain why, rather than the folks
>> who think we should follow industry precedence to justify that.
>>
>> 2. Assuming that I'm wrong, and ABI / ELF are in scope for
>> standardization, we would still have to do a lot of premliminary
>> work to determine that. For example, we may end up wanting to
>> standardize that maps are put into .maps sections in an ELF file, but
>> that would only make sense if we created a document standardizing
>> cross-platform map types. The same holds true for cross-platform
>> program types, etc. The dependency DAG for discussing ELF has a depth
>> of at least 2, and given that it's as-yet unclear whether ELF / psABI
>> is an appropriate topic for standardization in the first place, it
>> really feels to me like leaving it out of the WG is the right move.
>>
>> Thanks,
>> David
>>
>>>
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
>>> Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>>
>>>
>>
>>
>>
>>> --
>>> Bpf mailing list
>>> Bpf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bpf
>>
>> --
>> Bpf mailing list
>> Bpf@ietf.org <mailto:Bpf@ietf.org>
>> https://www.ietf.org/mailman/listinfo/bpf <https://www.ietf.org/mailman/listinfo/bpf>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-24 21:06 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-24 21:06 UTC (permalink / raw)
To: Suresh Krishnan
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig, Dave Thaler
> Hi David,
> I just want to provide a quick clarification from the IETF side
> regarding categories of RFCs. Not all the RFCs we produce are
> standards. On a broad level we have standards track and informational
> documents (among others; more details in RFC2026). I do believe there
> is value in *documenting* some of the items that belong in an ABI such
> as the calling convention (similar to what is in Section 2 of the ISA
> draft). Similarly, there is value in documenting conventions and
> guidelines for creating portable binaries if we believe that is a
> useful goal, even though there will be a lot of programs that will not
> be portable (e.g. using cgroups). I would not expect these to be
> Standards track documents but rather Informational specifications to
> help implementers. If that sounds reasonable we can keep the text in
> the charter (with some minor rewording) and work on categorizing
> potential deliverables by Document Status (as would anyway be
> necessitated by Éric Vyncke’s BLOCK).
I wonder. Lets suppose the ABI and ELF extensions are maintained and
evolved in the usual way it is done for all other architectures, i.e.
in the kernel git repository or a dedicatd public one, in textual form,
under a free software license, not requiring copyright assignments nor
bureocratic processes to be updated, etc. Could then the WG edit and
publish "snapshots" whenever considered appropriate, and release them as
subsequent versions of an IETF Informational specification, or some
other suitable kind of IETF document?
If something like that would be doable, maybe we could concile the
practicality of the usual approach with the more formal character of an
IETF document?
> Regards
> Suresh
>
>> On May 23, 2023, at 4:28 PM, David Vernet <void@manifault.com> wrote:
>>
>> On Tue, May 23, 2023 at 01:58:18PM -0400, Michael Richardson wrote:
>>>
>>> David Vernet <void@manifault.com <mailto:void@manifault.com>> wrote:
>>>> As far as I know (please correct me if I'm wrong), there isn't really a
>>>> precedence for standardizing ABIs like this. For example, x86 calling
>>>
>>> All of the eBPF work seems unprecedented.
>>> I don't see having this in the charter is a problem.
>>>
>>> We may fail to get consensus on it, and not make a milestone, but I don't see
>>> a reason not to be allowed to talk about this.
>>> (and maybe in the end, it's a no-op)
>>
>> Hi Michael,
>>
>> So apologies in advance if my lack of experience with IETF proceedings
>> is glaringly obvious, and I'd appreciate clarification in any situation
>> in which I'm mistaken.
>>
>> My understanding based on the conversations that I've had thus far is
>> that part of the goal of arriving at the finalized WG charter is to
>> determine what's in scope and out of scope. It's a bit of a murky
>> proposition because some things that we think _could_ be in scope, such
>> as in this case topics related to psABI, may not end up having a
>> document if we can't get consensus. In other words, being in the WG
>> charter doesn't imply that something is in-scope and will have a
>> document written, but _not_ being in the charter does preclude it from
>> being discussed in this iteration of the WG because of this line:
>>
>>> The working group shall not adopt new work until these
>>> documents have progressed to working group last call.
>>
>> The implication of this is that it's not necessarily a problem to have
>> some false-positives in terms of what we cover, but it can be
>> problematic if we leave out something important because we'll have to
>> cover all of the other topics first. I'd imagine this would tend to make
>> the default behavior for deciding scope in WG charters to be permissive
>> rather than dissmive, which makes sense to me.
>>
>> Assuming I haven't already gone off the rails in terms of my
>> understanding, let me try to clarify why despite all that, I still think
>> it's warranted for us to remove psABI as part of the scope of the WG.
>> There are really two main reasons:
>>
>> 1. As is hopefully clear at this point, there is a wide and historical
>> industry precedence for not standardizing on psABI. For example, to
>> my knowledge, RISC-V [0] develops and ratifies the RISC-V ISA through
>> the RISC-V International Technical Working Groups, but there is no
>> such ratified standard or specification for RISC-V calling
>> conventions (the operative word of course being "convention"). The
>> same is true (to my knowledge) of _all_ psABI ELF extensions, as Jose
>> pointed out earlier in the conversation.
>>
>> [0]: https://riscv.org/technical/specifications/ <https://riscv.org/technical/specifications/>
>>
>> With all that said, unless there's more context behind why we think we
>> need to standardize psABI which hasn't yet been brought forward, I
>> don't see any way we'd achieve consensus when we discuss it in the
>> WG. And the reason I specifically think that's the case for ABI (ELF
>> or otherwise) is that there's such a well-established precedence
>> already for not standardizing it. I guess it's true that there's no
>> harm in including it and discussing it, but as things currently
>> stand, it also doesn't seem very productive to include it if there's
>> already (IMHO) reasonably clear evidence that it's out of scope. To
>> go back to my claim made in another email, I think the onus is on the
>> folks who think it's in scope to explain why, rather than the folks
>> who think we should follow industry precedence to justify that.
>>
>> 2. Assuming that I'm wrong, and ABI / ELF are in scope for
>> standardization, we would still have to do a lot of premliminary
>> work to determine that. For example, we may end up wanting to
>> standardize that maps are put into .maps sections in an ELF file, but
>> that would only make sense if we created a document standardizing
>> cross-platform map types. The same holds true for cross-platform
>> program types, etc. The dependency DAG for discussing ELF has a depth
>> of at least 2, and given that it's as-yet unclear whether ELF / psABI
>> is an appropriate topic for standardization in the first place, it
>> really feels to me like leaving it out of the WG is the right move.
>>
>> Thanks,
>> David
>>
>>>
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting )
>>> Sandelman Software Works Inc, Ottawa and Worldwide
>>>
>>>
>>>
>>>
>>
>>
>>
>>> --
>>> Bpf mailing list
>>> Bpf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bpf
>>
>> --
>> Bpf mailing list
>> Bpf@ietf.org <mailto:Bpf@ietf.org>
>> https://www.ietf.org/mailman/listinfo/bpf <https://www.ietf.org/mailman/listinfo/bpf>
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 16:05 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 16:05 UTC (permalink / raw)
To: Jose E. Marchesi, Suresh Krishnan
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig
Jose E. Marchesi <jemarch@gnu.org> writes:
[...]
> I wonder. Lets suppose the ABI and ELF extensions are maintained and evolved
> in the usual way it is done for all other architectures, i.e.
> in the kernel git repository or a dedicatd public one, in textual form, under a
> free software license, not requiring copyright assignments nor bureocratic
> processes to be updated, etc.
Let's not confuse code and documentation. Here we are discussing documentation
not code. For documentation, see the RISC-V standard in my previous email.
The calling convention document isn't part of a kernel git repository, it's part
of a standards group that is specific to RISC-V. That's what we're talking about here.
Dave
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 16:05 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 16:05 UTC (permalink / raw)
To: Jose E. Marchesi, Suresh Krishnan
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig
Jose E. Marchesi <jemarch@gnu.org> writes:
[...]
> I wonder. Lets suppose the ABI and ELF extensions are maintained and evolved
> in the usual way it is done for all other architectures, i.e.
> in the kernel git repository or a dedicatd public one, in textual form, under a
> free software license, not requiring copyright assignments nor bureocratic
> processes to be updated, etc.
Let's not confuse code and documentation. Here we are discussing documentation
not code. For documentation, see the RISC-V standard in my previous email.
The calling convention document isn't part of a kernel git repository, it's part
of a standards group that is specific to RISC-V. That's what we're talking about here.
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:25 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-26 17:25 UTC (permalink / raw)
To: Dave Thaler
Cc: Suresh Krishnan, David Vernet, Michael Richardson, bpf@ietf.org,
bpf, Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig
> Jose E. Marchesi <jemarch@gnu.org> writes:
> [...]
>> I wonder. Lets suppose the ABI and ELF extensions are maintained and evolved
>> in the usual way it is done for all other architectures, i.e.
>> in the kernel git repository or a dedicatd public one, in textual form, under a
>> free software license, not requiring copyright assignments nor bureocratic
>> processes to be updated, etc.
>
> Let's not confuse code and documentation. Here we are discussing documentation
> not code.
Hm. I don't think anyone is confusing code and documentation here.
> For documentation, see the RISC-V standard in my previous email. The
> calling convention document isn't part of a kernel git repository,
> it's part of a standards group that is specific to RISC-V. That's
> what we're talking about here.
The PDF you sent is an (outdated) fragment of the specification of the
ISA and some official ISA extensions, that just happens to contain a two
pages providing a very general indications on the calling conventions.
That is _not_ the ABI.
The official RISC-V psABI is maintained in [1], which is a git
repository, it is distributed under a creative-commons license CC-BY, is
updated, and it is open to external contributions via pull requests.
And yes, it happens that particular psABI is maintained by RISC-V via a
TG (Task Group) with a chair and a co-chair, and there is a well defined
process, documented in the policy.md file in that git repo. All the
bells and whistles. Sure.
In a similar way than the x86_64 psABI is maintained by Intel via HJ Lu
in another git repo, distributed under a creative-commons license CC-BY,
updated often, and open to external contributions via pull requests or
patches. Less bells and whistles (as far as I know HJ is no chair of
anything, gotta ask him) but a similar implementation.
I am attaching the RISC-V ABI policy at the end of this email.
Can IETF implement a similar process?
In particular:
1) Maintaining the ABI in a public git repository.
Like the RISC-V Foundation does.
2) Releasing the files in that repo under a free software license like
dual GPL/BSD, or a suitable Creative Commons like CC-BY.
Like the RISC-V Foundation does.
3) Allowing third-party like particulars and corporations to contribute
to the ABI (via patches to mailing list or pull requests) without the
need of a copyright assignment?
Like the RISC-V Foundation does.
4) Explicitly referring implementors to the git repo as the latest and
authoritative version of the document.
Like the RISC-V Foundation does.
If the answer is yes, then I will shut up, apologize for the noise, and
be as happy as a clam.
If the answer is no, well, I think I will still shut up, because I'm
getting a bit tired of always being the party pooper around here, and
the point has been made for your consideration, so more I cannot do.
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc
---
policy.md
# Policy for Merging Pull Requests
Each type of modification has a different policy, based on the following rules:
- Changes requiring linker changes
- Require an open source PoC implementation for binutils or LLD, either as a
patch on the mailing list/Phabricator as appropriate or in a GitHub fork
- Require at least one binutils developer **_AND_** one LLD developer to
approve
- Changes requiring compiler changes
- Require an open source PoC implementation for GCC or LLVM, either as a
patch on the mailing list/Phabricator as appropriate or in a GitHub fork
- Require at least one GCC developer **_AND_** one LLVM developer to approve
- Clarifications for currently-implemented behaviour
- Require approval from a developer of the corresponding component
(binutils/LLD or GCC/LLVM)
- General improvements and clarification
- One of the psABI TG chair or co-chair.
- Do **_NOT_** make incompatible changes
- Changes that break compatibility are generally not acceptable
- In the rare case there is a bug in the ABI that needs fixing and that
cannot be done in a backwards-compatible way, or possibly for some
edge-case behaviour that is not currently relied upon, breaking the ABI can
be considered, but will require both the psABI TG chair and co-chair to
approve, and is subject to the above requirements as appropriate
# FAQ
- Can I leave a comment, LGTM or approve the PR even if I am not a toolchain
developer or chair/co-chair?
- Don't hesitate to leave your comment, we encourage anyone who intends
to contribute to the RISC-V community to participate in discussion.
- When do I need to modify the compiler and/or linker?
- Changes and additions to the ELF format itself generally require linker
changes, e.g. new relocation types, new flags in the `e_flags` field, new
sections and new symbol flags.
- Changes and additions to calling conventions and code models generally
require compiler changes.
- Who are the psABI TG chair and co-chair?
- The current chair is Kito Cheng ([@kito-cheng]) and the current co-chair is
Jessica Clarke ([@jrtc27]).
- Where can I find a RISC-V GCC/LLVM/binutils/LLD developer to review my PR?
- The psABI TG chair or co-chair will generally contact the right people as
needed for reviews, but in case you want to reach out yourself you can find
an incomplete list from [RISC-V International's wiki page].
[@kito-cheng]: https://github.com/kito-cheng
[@jrtc27]: https://github.com/jrtc27
[RISC-V International's wiki page]: https://wiki.riscv.org/display/TECH/Toolchain+Projects
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:25 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-26 17:25 UTC (permalink / raw)
To: Dave Thaler
Cc: Suresh Krishnan, David Vernet, Michael Richardson, bpf@ietf.org,
bpf, Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig
> Jose E. Marchesi <jemarch@gnu.org> writes:
> [...]
>> I wonder. Lets suppose the ABI and ELF extensions are maintained and evolved
>> in the usual way it is done for all other architectures, i.e.
>> in the kernel git repository or a dedicatd public one, in textual form, under a
>> free software license, not requiring copyright assignments nor bureocratic
>> processes to be updated, etc.
>
> Let's not confuse code and documentation. Here we are discussing documentation
> not code.
Hm. I don't think anyone is confusing code and documentation here.
> For documentation, see the RISC-V standard in my previous email. The
> calling convention document isn't part of a kernel git repository,
> it's part of a standards group that is specific to RISC-V. That's
> what we're talking about here.
The PDF you sent is an (outdated) fragment of the specification of the
ISA and some official ISA extensions, that just happens to contain a two
pages providing a very general indications on the calling conventions.
That is _not_ the ABI.
The official RISC-V psABI is maintained in [1], which is a git
repository, it is distributed under a creative-commons license CC-BY, is
updated, and it is open to external contributions via pull requests.
And yes, it happens that particular psABI is maintained by RISC-V via a
TG (Task Group) with a chair and a co-chair, and there is a well defined
process, documented in the policy.md file in that git repo. All the
bells and whistles. Sure.
In a similar way than the x86_64 psABI is maintained by Intel via HJ Lu
in another git repo, distributed under a creative-commons license CC-BY,
updated often, and open to external contributions via pull requests or
patches. Less bells and whistles (as far as I know HJ is no chair of
anything, gotta ask him) but a similar implementation.
I am attaching the RISC-V ABI policy at the end of this email.
Can IETF implement a similar process?
In particular:
1) Maintaining the ABI in a public git repository.
Like the RISC-V Foundation does.
2) Releasing the files in that repo under a free software license like
dual GPL/BSD, or a suitable Creative Commons like CC-BY.
Like the RISC-V Foundation does.
3) Allowing third-party like particulars and corporations to contribute
to the ABI (via patches to mailing list or pull requests) without the
need of a copyright assignment?
Like the RISC-V Foundation does.
4) Explicitly referring implementors to the git repo as the latest and
authoritative version of the document.
Like the RISC-V Foundation does.
If the answer is yes, then I will shut up, apologize for the noise, and
be as happy as a clam.
If the answer is no, well, I think I will still shut up, because I'm
getting a bit tired of always being the party pooper around here, and
the point has been made for your consideration, so more I cannot do.
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc
---
policy.md
# Policy for Merging Pull Requests
Each type of modification has a different policy, based on the following rules:
- Changes requiring linker changes
- Require an open source PoC implementation for binutils or LLD, either as a
patch on the mailing list/Phabricator as appropriate or in a GitHub fork
- Require at least one binutils developer **_AND_** one LLD developer to
approve
- Changes requiring compiler changes
- Require an open source PoC implementation for GCC or LLVM, either as a
patch on the mailing list/Phabricator as appropriate or in a GitHub fork
- Require at least one GCC developer **_AND_** one LLVM developer to approve
- Clarifications for currently-implemented behaviour
- Require approval from a developer of the corresponding component
(binutils/LLD or GCC/LLVM)
- General improvements and clarification
- One of the psABI TG chair or co-chair.
- Do **_NOT_** make incompatible changes
- Changes that break compatibility are generally not acceptable
- In the rare case there is a bug in the ABI that needs fixing and that
cannot be done in a backwards-compatible way, or possibly for some
edge-case behaviour that is not currently relied upon, breaking the ABI can
be considered, but will require both the psABI TG chair and co-chair to
approve, and is subject to the above requirements as appropriate
# FAQ
- Can I leave a comment, LGTM or approve the PR even if I am not a toolchain
developer or chair/co-chair?
- Don't hesitate to leave your comment, we encourage anyone who intends
to contribute to the RISC-V community to participate in discussion.
- When do I need to modify the compiler and/or linker?
- Changes and additions to the ELF format itself generally require linker
changes, e.g. new relocation types, new flags in the `e_flags` field, new
sections and new symbol flags.
- Changes and additions to calling conventions and code models generally
require compiler changes.
- Who are the psABI TG chair and co-chair?
- The current chair is Kito Cheng ([@kito-cheng]) and the current co-chair is
Jessica Clarke ([@jrtc27]).
- Where can I find a RISC-V GCC/LLVM/binutils/LLD developer to review my PR?
- The psABI TG chair or co-chair will generally contact the right people as
needed for reviews, but in case you want to reach out yourself you can find
an incomplete list from [RISC-V International's wiki page].
[@kito-cheng]: https://github.com/kito-cheng
[@jrtc27]: https://github.com/jrtc27
[RISC-V International's wiki page]: https://wiki.riscv.org/display/TECH/Toolchain+Projects
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-25 7:44 ` Christoph Hellwig
0 siblings, 0 replies; 59+ messages in thread
From: Christoph Hellwig @ 2023-05-25 7:44 UTC (permalink / raw)
To: David Vernet
Cc: Michael Richardson, bpf@ietf.org, bpf, Alexei Starovoitov,
Jose E. Marchesi, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig, Dave Thaler
I'm really lost in this discussion. All aspects of the ABI are
a required part of interoperability. And one of the promises of
this IETF eBPF project is to provide for this interoperability.
This is a very different situation from the binary ABI for Linux
or Windows, which has traditionally never been interoperable between
vendors, odd examples like iBCS2 [1] notwithstanding.
I'm fine with watering down the wording in the charter a bit in not
beeing too specific what documebts we want to work on for the binary
compatibility, but I think having it is essential.
What do we gain by not having the full binary interface in the working
group scope?
[1] https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-25 7:44 ` Christoph Hellwig
0 siblings, 0 replies; 59+ messages in thread
From: Christoph Hellwig @ 2023-05-25 7:44 UTC (permalink / raw)
To: David Vernet
Cc: Michael Richardson, bpf@ietf.org, bpf, Alexei Starovoitov,
Jose E. Marchesi, Erik Kline, Suresh Krishnan (sureshk),
Christoph Hellwig, Dave Thaler
I'm really lost in this discussion. All aspects of the ABI are
a required part of interoperability. And one of the promises of
this IETF eBPF project is to provide for this interoperability.
This is a very different situation from the binary ABI for Linux
or Windows, which has traditionally never been interoperable between
vendors, odd examples like iBCS2 [1] notwithstanding.
I'm fine with watering down the wording in the charter a bit in not
beeing too specific what documebts we want to work on for the binary
compatibility, but I think having it is essential.
What do we gain by not having the full binary interface in the working
group scope?
[1] https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-25 10:14 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-25 10:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Dave Thaler
> I'm really lost in this discussion. All aspects of the ABI are
> a required part of interoperability. And one of the promises of
> this IETF eBPF project is to provide for this interoperability.
>
> This is a very different situation from the binary ABI for Linux
> or Windows, which has traditionally never been interoperable between
> vendors, odd examples like iBCS2 [1] notwithstanding.
The situation is not that different from the perspective of the
producers of the programs. Even within the context of a single system
the different vendors of compilers, assemblers, linkers, libc, and other
tools need to coordinate and agree on conventions so they all produce
compatible programs which are able to interoperate and run on the
system.
The psABI is what provides for this interoperability, and it works just
fine.
None of these psABI are maintained as standards in the strong and strict
sense (ISO, ANSI, IETF, whatever) and I am just wondering about the
convenience of doing so for the BPF ABI, given the nature of these.
I reckon the perspective from the system side may be different.
No more binary program solipsism :)
Example:
If I understood correctly from the thread, an IETF standard document is
not supposed to be updated regularly. Instead, it is expected to be
carefully designed to rely on "codepoints" so all additions are optional
and are released in their own document or supplement.
As someone who uses ABIs on the toolchain side, and who contributes to
some of them, I am personally skeptical that schema can actually
accomodate the reality of an alive and evolving ABI, especially one as
young as BPF. The resulting "authoritative" documents risk to be
outdated more often than not, and end being a curiosity that nobody
actually uses.
I would be happy to be proved wrong, and of course the WG is free to not
share my concerns, but I have to voice them.
> I'm fine with watering down the wording in the charter a bit in not
> beeing too specific what documebts we want to work on for the binary
> compatibility, but I think having it is essential.
>
> What do we gain by not having the full binary interface in the working
> group scope?
>
> [1] https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-25 10:14 ` Jose E. Marchesi
0 siblings, 0 replies; 59+ messages in thread
From: Jose E. Marchesi @ 2023-05-25 10:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk),
Dave Thaler
> I'm really lost in this discussion. All aspects of the ABI are
> a required part of interoperability. And one of the promises of
> this IETF eBPF project is to provide for this interoperability.
>
> This is a very different situation from the binary ABI for Linux
> or Windows, which has traditionally never been interoperable between
> vendors, odd examples like iBCS2 [1] notwithstanding.
The situation is not that different from the perspective of the
producers of the programs. Even within the context of a single system
the different vendors of compilers, assemblers, linkers, libc, and other
tools need to coordinate and agree on conventions so they all produce
compatible programs which are able to interoperate and run on the
system.
The psABI is what provides for this interoperability, and it works just
fine.
None of these psABI are maintained as standards in the strong and strict
sense (ISO, ANSI, IETF, whatever) and I am just wondering about the
convenience of doing so for the BPF ABI, given the nature of these.
I reckon the perspective from the system side may be different.
No more binary program solipsism :)
Example:
If I understood correctly from the thread, an IETF standard document is
not supposed to be updated regularly. Instead, it is expected to be
carefully designed to rely on "codepoints" so all additions are optional
and are released in their own document or supplement.
As someone who uses ABIs on the toolchain side, and who contributes to
some of them, I am personally skeptical that schema can actually
accomodate the reality of an alive and evolving ABI, especially one as
young as BPF. The resulting "authoritative" documents risk to be
outdated more often than not, and end being a curiosity that nobody
actually uses.
I would be happy to be proved wrong, and of course the WG is free to not
share my concerns, but I have to voice them.
> I'm fine with watering down the wording in the charter a bit in not
> beeing too specific what documebts we want to work on for the binary
> compatibility, but I think having it is essential.
>
> What do we gain by not having the full binary interface in the working
> group scope?
>
> [1] https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 16:02 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 16:02 UTC (permalink / raw)
To: Jose E. Marchesi, Christoph Hellwig
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk)
Jose E. Marchesi wrote:
> > I'm really lost in this discussion. All aspects of the ABI are a
> > required part of interoperability. And one of the promises of this
> > IETF eBPF project is to provide for this interoperability.
> >
> > This is a very different situation from the binary ABI for Linux or
> > Windows, which has traditionally never been interoperable between
> > vendors, odd examples like iBCS2 [1] notwithstanding.
>
> The situation is not that different from the perspective of the producers of the
> programs. Even within the context of a single system the different vendors of
> compilers, assemblers, linkers, libc, and other tools need to coordinate and
> agree on conventions so they all produce compatible programs which are able
> to interoperate and run on the system.
>
> The psABI is what provides for this interoperability, and it works just fine.
>
> None of these psABI are maintained as standards in the strong and strict sense
> (ISO, ANSI, IETF, whatever) and I am just wondering about the convenience of
> doing so for the BPF ABI, given the nature of these.
The RISC-V calling convention is indeed maintained as a standard.
https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf is the relevant
document by RISC-V International which per https://riscv.org/about/ is a standards
organization. (I haven't participated in it, via the Confidential Computing Consortium I have interacted with some people who have.)
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.
> I reckon the perspective from the system side may be different.
> No more binary program solipsism :)
>
> Example:
>
> If I understood correctly from the thread, an IETF standard document is not
> supposed to be updated regularly. Instead, it is expected to be carefully
> designed to rely on "codepoints" so all additions are optional and are released
> in their own document or supplement.
>
> As someone who uses ABIs on the toolchain side, and who contributes to some
> of them, I am personally skeptical that schema can actually accomodate the
> reality of an alive and evolving ABI, especially one as young as BPF. The
> resulting "authoritative" documents risk to be outdated more often than not,
> and end being a curiosity that nobody actually uses.
>
> I would be happy to be proved wrong, and of course the WG is free to not share
> my concerns, but I have to voice them.
See the RISC-V document above.
Dave
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 16:02 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 16:02 UTC (permalink / raw)
To: Jose E. Marchesi, Christoph Hellwig
Cc: David Vernet, Michael Richardson, bpf@ietf.org, bpf,
Alexei Starovoitov, Erik Kline, Suresh Krishnan (sureshk)
Jose E. Marchesi wrote:
> > I'm really lost in this discussion. All aspects of the ABI are a
> > required part of interoperability. And one of the promises of this
> > IETF eBPF project is to provide for this interoperability.
> >
> > This is a very different situation from the binary ABI for Linux or
> > Windows, which has traditionally never been interoperable between
> > vendors, odd examples like iBCS2 [1] notwithstanding.
>
> The situation is not that different from the perspective of the producers of the
> programs. Even within the context of a single system the different vendors of
> compilers, assemblers, linkers, libc, and other tools need to coordinate and
> agree on conventions so they all produce compatible programs which are able
> to interoperate and run on the system.
>
> The psABI is what provides for this interoperability, and it works just fine.
>
> None of these psABI are maintained as standards in the strong and strict sense
> (ISO, ANSI, IETF, whatever) and I am just wondering about the convenience of
> doing so for the BPF ABI, given the nature of these.
The RISC-V calling convention is indeed maintained as a standard.
https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf is the relevant
document by RISC-V International which per https://riscv.org/about/ is a standards
organization. (I haven't participated in it, via the Confidential Computing Consortium I have interacted with some people who have.)
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.
> I reckon the perspective from the system side may be different.
> No more binary program solipsism :)
>
> Example:
>
> If I understood correctly from the thread, an IETF standard document is not
> supposed to be updated regularly. Instead, it is expected to be carefully
> designed to rely on "codepoints" so all additions are optional and are released
> in their own document or supplement.
>
> As someone who uses ABIs on the toolchain side, and who contributes to some
> of them, I am personally skeptical that schema can actually accomodate the
> reality of an alive and evolving ABI, especially one as young as BPF. The
> resulting "authoritative" documents risk to be outdated more often than not,
> and end being a curiosity that nobody actually uses.
>
> I would be happy to be proved wrong, and of course the WG is free to not share
> my concerns, but I have to voice them.
See the RISC-V document above.
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 16:55 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-26 16:55 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk)
On Fri, May 26, 2023 at 04:02:46PM +0000, Dave Thaler wrote:
> Jose E. Marchesi wrote:
> > > I'm really lost in this discussion. All aspects of the ABI are a
> > > required part of interoperability. And one of the promises of this
> > > IETF eBPF project is to provide for this interoperability.
> > >
> > > This is a very different situation from the binary ABI for Linux or
> > > Windows, which has traditionally never been interoperable between
> > > vendors, odd examples like iBCS2 [1] notwithstanding.
> >
> > The situation is not that different from the perspective of the producers of the
> > programs. Even within the context of a single system the different vendors of
> > compilers, assemblers, linkers, libc, and other tools need to coordinate and
> > agree on conventions so they all produce compatible programs which are able
> > to interoperate and run on the system.
> >
> > The psABI is what provides for this interoperability, and it works just fine.
> >
> > None of these psABI are maintained as standards in the strong and strict sense
> > (ISO, ANSI, IETF, whatever) and I am just wondering about the convenience of
> > doing so for the BPF ABI, given the nature of these.
>
> The RISC-V calling convention is indeed maintained as a standard.
> https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf is the relevant
> document by RISC-V International which per https://riscv.org/about/ is a standards
> organization. (I haven't participated in it, via the Confidential Computing Consortium I have interacted with some people who have.)
Dave,
The following is a quote from version 1.0 of the RISC-V ABI
Specification [0]:
[0]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0/riscv-abi.pdf
> This specification is written in collaboration with the development
> communities of the major opensource toolchain and operating system
> communities, and as such specifies what has been agreed upon and
> implemented. As a result, any changes to this specification that are
> not backwards compatible would break ABI compatibility for those
> toolchains, which is not permitted unless for features explicitly
> marked as experimental, and so will not be made unless absolutely
> necessary, regardless of whether the specification is a pre-release
> version, ratified version or anything in between. 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.
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?
Thanks,
David
> > I reckon the perspective from the system side may be different.
> > No more binary program solipsism :)
> >
> > Example:
> >
> > If I understood correctly from the thread, an IETF standard document is not
> > supposed to be updated regularly. Instead, it is expected to be carefully
> > designed to rely on "codepoints" so all additions are optional and are released
> > in their own document or supplement.
> >
> > As someone who uses ABIs on the toolchain side, and who contributes to some
> > of them, I am personally skeptical that schema can actually accomodate the
> > reality of an alive and evolving ABI, especially one as young as BPF. The
> > resulting "authoritative" documents risk to be outdated more often than not,
> > and end being a curiosity that nobody actually uses.
> >
> > I would be happy to be proved wrong, and of course the WG is free to not share
> > my concerns, but I have to voice them.
>
> See the RISC-V document above.
>
> Dave
>
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 16:55 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-26 16:55 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk)
On Fri, May 26, 2023 at 04:02:46PM +0000, Dave Thaler wrote:
> Jose E. Marchesi wrote:
> > > I'm really lost in this discussion. All aspects of the ABI are a
> > > required part of interoperability. And one of the promises of this
> > > IETF eBPF project is to provide for this interoperability.
> > >
> > > This is a very different situation from the binary ABI for Linux or
> > > Windows, which has traditionally never been interoperable between
> > > vendors, odd examples like iBCS2 [1] notwithstanding.
> >
> > The situation is not that different from the perspective of the producers of the
> > programs. Even within the context of a single system the different vendors of
> > compilers, assemblers, linkers, libc, and other tools need to coordinate and
> > agree on conventions so they all produce compatible programs which are able
> > to interoperate and run on the system.
> >
> > The psABI is what provides for this interoperability, and it works just fine.
> >
> > None of these psABI are maintained as standards in the strong and strict sense
> > (ISO, ANSI, IETF, whatever) and I am just wondering about the convenience of
> > doing so for the BPF ABI, given the nature of these.
>
> The RISC-V calling convention is indeed maintained as a standard.
> https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf is the relevant
> document by RISC-V International which per https://riscv.org/about/ is a standards
> organization. (I haven't participated in it, via the Confidential Computing Consortium I have interacted with some people who have.)
Dave,
The following is a quote from version 1.0 of the RISC-V ABI
Specification [0]:
[0]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0/riscv-abi.pdf
> This specification is written in collaboration with the development
> communities of the major opensource toolchain and operating system
> communities, and as such specifies what has been agreed upon and
> implemented. As a result, any changes to this specification that are
> not backwards compatible would break ABI compatibility for those
> toolchains, which is not permitted unless for features explicitly
> marked as experimental, and so will not be made unless absolutely
> necessary, regardless of whether the specification is a pre-release
> version, ratified version or anything in between. 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.
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?
Thanks,
David
> > I reckon the perspective from the system side may be different.
> > No more binary program solipsism :)
> >
> > Example:
> >
> > If I understood correctly from the thread, an IETF standard document is not
> > supposed to be updated regularly. Instead, it is expected to be carefully
> > designed to rely on "codepoints" so all additions are optional and are released
> > in their own document or supplement.
> >
> > As someone who uses ABIs on the toolchain side, and who contributes to some
> > of them, I am personally skeptical that schema can actually accomodate the
> > reality of an alive and evolving ABI, especially one as young as BPF. The
> > resulting "authoritative" documents risk to be outdated more often than not,
> > and end being a curiosity that nobody actually uses.
> >
> > I would be happy to be proved wrong, and of course the WG is free to not share
> > my concerns, but I have to voice them.
>
> See the RISC-V document above.
>
> Dave
>
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:01 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 17:01 UTC (permalink / raw)
To: David Vernet
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk)
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.
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.
Dave
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:01 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 17:01 UTC (permalink / raw)
To: David Vernet
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk)
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.
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.
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:19 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-26 17:19 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk), Lorenz Bauer
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
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:19 ` David Vernet
0 siblings, 0 replies; 59+ messages in thread
From: David Vernet @ 2023-05-26 17:19 UTC (permalink / raw)
To: Dave Thaler
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk), Lorenz Bauer
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
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:30 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 17:30 UTC (permalink / raw)
To: David Vernet
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk), Lorenz Bauer
David Vernet <void@manifault.com> writes:
> 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?
Yes, other than some punctuation nits (https://github.com/ekline/bpf/pull/7).
Dave
> 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
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-26 17:30 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-26 17:30 UTC (permalink / raw)
To: David Vernet
Cc: Jose E. Marchesi, Christoph Hellwig, Michael Richardson,
bpf@ietf.org, bpf, Alexei Starovoitov, Erik Kline,
Suresh Krishnan (sureshk), Lorenz Bauer
David Vernet <void@manifault.com> writes:
> 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?
Yes, other than some punctuation nits (https://github.com/ekline/bpf/pull/7).
Dave
> 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
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 3:48 ` Christoph Hellwig
0 siblings, 0 replies; 59+ messages in thread
From: Christoph Hellwig @ 2023-05-31 3:48 UTC (permalink / raw)
To: Dave Thaler
Cc: David Vernet, Jose E. Marchesi, Christoph Hellwig,
Michael Richardson, bpf@ietf.org, bpf, Alexei Starovoitov,
Erik Kline, Suresh Krishnan (sureshk), Lorenz Bauer
On Fri, May 26, 2023 at 05:30:11PM +0000, Dave Thaler wrote:
> David Vernet <void@manifault.com> writes:
> > 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?
>
> Yes, other than some punctuation nits (https://github.com/ekline/bpf/pull/7).
I can live with it as well.
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 3:48 ` Christoph Hellwig
0 siblings, 0 replies; 59+ messages in thread
From: Christoph Hellwig @ 2023-05-31 3:48 UTC (permalink / raw)
To: Dave Thaler
Cc: David Vernet, Jose E. Marchesi, Christoph Hellwig,
Michael Richardson, bpf@ietf.org, bpf, Alexei Starovoitov,
Erik Kline, Suresh Krishnan (sureshk), Lorenz Bauer
On Fri, May 26, 2023 at 05:30:11PM +0000, Dave Thaler wrote:
> David Vernet <void@manifault.com> writes:
> > 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?
>
> Yes, other than some punctuation nits (https://github.com/ekline/bpf/pull/7).
I can live with it as well.
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 19:38 ` Michael Richardson
0 siblings, 0 replies; 59+ messages in thread
From: Michael Richardson @ 2023-05-31 19:38 UTC (permalink / raw)
To: bpf@ietf.org, bpf
[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]
I assume that one use cases is where a VM (windows or Linux inside) does a
eBPF (XDP) load into a virtual network interface, and the hypervisor manages
to push that down to some engine in a physical card.
In that case, we might have mixes of Windows, Linux and network card
implementations of eBPF on the same "transaction" path.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
[-- Attachment #2: Type: text/plain, Size: 76 bytes --]
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 19:38 ` Michael Richardson
0 siblings, 0 replies; 59+ messages in thread
From: Michael Richardson @ 2023-05-31 19:38 UTC (permalink / raw)
To: bpf@ietf.org, bpf
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
I assume that one use cases is where a VM (windows or Linux inside) does a
eBPF (XDP) load into a virtual network interface, and the hypervisor manages
to push that down to some engine in a physical card.
In that case, we might have mixes of Windows, Linux and network card
implementations of eBPF on the same "transaction" path.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 19:44 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-31 19:44 UTC (permalink / raw)
To: Michael Richardson, bpf@ietf.org, bpf
> -----Original Message-----
> From: Bpf <bpf-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Wednesday, May 31, 2023 12:38 PM
> To: bpf@ietf.org; bpf <bpf@vger.kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
>
> I assume that one use cases is where a VM (windows or Linux inside) does a
> eBPF (XDP) load into a virtual network interface, and the hypervisor manages
> to push that down to some engine in a physical card.
>
> In that case, we might have mixes of Windows, Linux and network card
> implementations of eBPF on the same "transaction" path.
Yes, exactly right.
Dave
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 19:44 ` Dave Thaler
0 siblings, 0 replies; 59+ messages in thread
From: Dave Thaler @ 2023-05-31 19:44 UTC (permalink / raw)
To: Michael Richardson, bpf@ietf.org, bpf
> -----Original Message-----
> From: Bpf <bpf-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Wednesday, May 31, 2023 12:38 PM
> To: bpf@ietf.org; bpf <bpf@vger.kernel.org>
> Subject: Re: [Bpf] IETF BPF working group draft charter
>
>
> I assume that one use cases is where a VM (windows or Linux inside) does a
> eBPF (XDP) load into a virtual network interface, and the hypervisor manages
> to push that down to some engine in a physical card.
>
> In that case, we might have mixes of Windows, Linux and network card
> implementations of eBPF on the same "transaction" path.
Yes, exactly right.
Dave
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-06-01 17:40 ` Michael Richardson
0 siblings, 0 replies; 59+ messages in thread
From: Michael Richardson @ 2023-06-01 17:40 UTC (permalink / raw)
To: Dave Thaler; +Cc: bpf@ietf.org, bpf
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>> I assume that one use cases is where a VM (windows or Linux inside)
>> does a eBPF (XDP) load into a virtual network interface, and the
>> hypervisor manages to push that down to some engine in a physical
>> card.
>>
>> In that case, we might have mixes of Windows, Linux and network card
>> implementations of eBPF on the same "transaction" path.
> Yes, exactly right.
Okay, I'm unclear if that implies that we need all the discussed ELF and ABI issues
to be compatible all the way down. Or if each layer can do it's adaptation
in incompatible ways, and that's okay.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
^ permalink raw reply [flat|nested] 59+ messages in thread* Re: [Bpf] IETF BPF working group draft charter
@ 2023-06-01 17:40 ` Michael Richardson
0 siblings, 0 replies; 59+ messages in thread
From: Michael Richardson @ 2023-06-01 17:40 UTC (permalink / raw)
To: Dave Thaler; +Cc: bpf@ietf.org, bpf
[-- Attachment #1.1: Type: text/plain, Size: 808 bytes --]
Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>> I assume that one use cases is where a VM (windows or Linux inside)
>> does a eBPF (XDP) load into a virtual network interface, and the
>> hypervisor manages to push that down to some engine in a physical
>> card.
>>
>> In that case, we might have mixes of Windows, Linux and network card
>> implementations of eBPF on the same "transaction" path.
> Yes, exactly right.
Okay, I'm unclear if that implies that we need all the discussed ELF and ABI issues
to be compatible all the way down. Or if each layer can do it's adaptation
in incompatible ways, and that's okay.
--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
[-- Attachment #2: Type: text/plain, Size: 76 bytes --]
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 3:47 ` Christoph Hellwig
0 siblings, 0 replies; 59+ messages in thread
From: Christoph Hellwig @ 2023-05-31 3:47 UTC (permalink / raw)
To: Dave Thaler
Cc: David Vernet, Jose E. Marchesi, Christoph Hellwig,
Michael Richardson, bpf@ietf.org, bpf, Alexei Starovoitov,
Erik Kline, Suresh Krishnan (sureshk)
On Fri, May 26, 2023 at 05:01:57PM +0000, Dave Thaler wrote:
> 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.
>
> 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.
This would be even more important for any of the potential NVMe use
cases. Compared to even ebpf-for-windows it is a fairly niche use case,
and the last thing we'd need was our own ABI and toolchain.
^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [Bpf] IETF BPF working group draft charter
@ 2023-05-31 3:47 ` Christoph Hellwig
0 siblings, 0 replies; 59+ messages in thread
From: Christoph Hellwig @ 2023-05-31 3:47 UTC (permalink / raw)
To: Dave Thaler
Cc: David Vernet, Jose E. Marchesi, Christoph Hellwig,
Michael Richardson, bpf@ietf.org, bpf, Alexei Starovoitov,
Erik Kline, Suresh Krishnan (sureshk)
On Fri, May 26, 2023 at 05:01:57PM +0000, Dave Thaler wrote:
> 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.
>
> 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.
This would be even more important for any of the potential NVMe use
cases. Compared to even ebpf-for-windows it is a fairly niche use case,
and the last thing we'd need was our own ABI and toolchain.
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
^ permalink raw reply [flat|nested] 59+ messages in thread