From: David Vernet <void@manifault.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "bpf@ietf.org" <bpf@ietf.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Erik Kline <ek.ietf@gmail.com>,
"Suresh Krishnan (sureshk)" <sureshk@cisco.com>,
Christoph Hellwig <hch@infradead.org>,
Dave Thaler <dthaler@microsoft.com>
Subject: Re: [Bpf] IETF BPF working group draft charter
Date: Tue, 23 May 2023 15:28:27 -0500 [thread overview]
Message-ID: <20230523202827.GA33347@maniforge> (raw)
In-Reply-To: <18272.1684864698@localhost>
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
WARNING: multiple messages have this Message-ID (diff)
From: David Vernet <void@manifault.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "bpf@ietf.org" <bpf@ietf.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Erik Kline <ek.ietf@gmail.com>,
"Suresh Krishnan (sureshk)" <sureshk@cisco.com>,
Christoph Hellwig <hch@infradead.org>,
Dave Thaler <dthaler@microsoft.com>
Subject: Re: [Bpf] IETF BPF working group draft charter
Date: Tue, 23 May 2023 15:28:27 -0500 [thread overview]
Message-ID: <20230523202827.GA33347@maniforge> (raw)
Message-ID: <20230523202827.bh0t0MsqWqn1bBeSo5b82ErOGwm0yZzqeW2_LNhtwJw@z> (raw)
In-Reply-To: <18272.1684864698@localhost>
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
next prev parent reply other threads:[~2023-05-23 20:28 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <PH7PR21MB38780769D482CC5F83768D3CA37E9@PH7PR21MB3878.namprd21.prod.outlook.com>
[not found] ` <87v8grkn67.fsf@gnu.org>
2023-05-17 18:19 ` [Bpf] IETF BPF working group draft charter Dave Thaler
2023-05-17 18:19 ` Dave Thaler
2023-05-17 21:00 ` David Vernet
2023-05-17 21:00 ` David Vernet
2023-05-17 21:13 ` Dave Thaler
2023-05-17 21:13 ` Dave Thaler
2023-05-18 17:33 ` Jose E. Marchesi
2023-05-18 17:33 ` Jose E. Marchesi
2023-05-18 19:42 ` Dave Thaler
2023-05-18 19:42 ` Dave Thaler
2023-05-23 16:32 ` David Vernet
2023-05-23 16:32 ` David Vernet
2023-05-23 16:50 ` Dave Thaler
2023-05-23 16:50 ` Dave Thaler
2023-05-23 17:15 ` David Vernet
2023-05-23 17:15 ` David Vernet
2023-05-23 19:08 ` David Vernet
2023-05-23 19:08 ` David Vernet
2023-05-23 19:42 ` Erik Kline
2023-05-23 19:42 ` Erik Kline
2023-05-23 19:47 ` Jose E. Marchesi
2023-05-23 19:47 ` Jose E. Marchesi
2023-05-23 17:58 ` Michael Richardson
2023-05-23 17:58 ` Michael Richardson
2023-05-23 18:25 ` Dave Thaler
2023-05-23 18:25 ` Dave Thaler
2023-05-23 20:28 ` David Vernet [this message]
2023-05-23 20:28 ` David Vernet
2023-05-24 20:38 ` Suresh Krishnan
2023-05-24 21:06 ` Jose E. Marchesi
2023-05-24 21:06 ` Jose E. Marchesi
2023-05-26 16:05 ` Dave Thaler
2023-05-26 16:05 ` Dave Thaler
2023-05-26 17:25 ` Jose E. Marchesi
2023-05-26 17:25 ` Jose E. Marchesi
2023-05-25 7:44 ` Christoph Hellwig
2023-05-25 7:44 ` Christoph Hellwig
2023-05-25 10:14 ` Jose E. Marchesi
2023-05-25 10:14 ` Jose E. Marchesi
2023-05-26 16:02 ` Dave Thaler
2023-05-26 16:02 ` Dave Thaler
2023-05-26 16:55 ` David Vernet
2023-05-26 16:55 ` David Vernet
2023-05-26 17:01 ` Dave Thaler
2023-05-26 17:01 ` Dave Thaler
2023-05-26 17:19 ` David Vernet
2023-05-26 17:19 ` David Vernet
2023-05-26 17:30 ` Dave Thaler
2023-05-26 17:30 ` Dave Thaler
2023-05-31 3:48 ` Christoph Hellwig
2023-05-31 3:48 ` Christoph Hellwig
2023-05-31 19:38 ` Michael Richardson
2023-05-31 19:38 ` Michael Richardson
2023-05-31 19:44 ` Dave Thaler
2023-05-31 19:44 ` Dave Thaler
2023-06-01 17:40 ` Michael Richardson
2023-06-01 17:40 ` Michael Richardson
2023-05-31 3:47 ` Christoph Hellwig
2023-05-31 3:47 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230523202827.GA33347@maniforge \
--to=void@manifault.com \
--cc=ast@kernel.org \
--cc=bpf@ietf.org \
--cc=bpf@vger.kernel.org \
--cc=dthaler@microsoft.com \
--cc=ek.ietf@gmail.com \
--cc=hch@infradead.org \
--cc=jemarch@gnu.org \
--cc=mcr+ietf@sandelman.ca \
--cc=sureshk@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.