From: "Jose E. Marchesi" <jemarch@gnu.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: David Vernet <void@manifault.com>,
Michael Richardson <mcr+ietf@sandelman.ca>,
"bpf@ietf.org" <bpf@ietf.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Erik Kline <ek.ietf@gmail.com>,
"Suresh Krishnan (sureshk)" <sureshk@cisco.com>,
Dave Thaler <dthaler@microsoft.com>
Subject: Re: [Bpf] IETF BPF working group draft charter
Date: Thu, 25 May 2023 12:14:29 +0200 [thread overview]
Message-ID: <87y1lclnui.fsf@gnu.org> (raw)
In-Reply-To: <ZG8R3JgOPHo7xn61@infradead.org> (Christoph Hellwig's message of "Thu, 25 May 2023 00:44:28 -0700")
> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Jose E. Marchesi" <jemarch@gnu.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: David Vernet <void@manifault.com>,
Michael Richardson <mcr+ietf@sandelman.ca>,
"bpf@ietf.org" <bpf@ietf.org>, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Erik Kline <ek.ietf@gmail.com>,
"Suresh Krishnan (sureshk)" <sureshk@cisco.com>,
Dave Thaler <dthaler@microsoft.com>
Subject: Re: [Bpf] IETF BPF working group draft charter
Date: Thu, 25 May 2023 12:14:29 +0200 [thread overview]
Message-ID: <87y1lclnui.fsf@gnu.org> (raw)
Message-ID: <20230525101429.0cylpSLFMcXNBxEWOEGs8NVklJPusiCkDP4_hVdllzY@z> (raw)
In-Reply-To: <ZG8R3JgOPHo7xn61@infradead.org> (Christoph Hellwig's message of "Thu, 25 May 2023 00:44:28 -0700")
> 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
next prev parent reply other threads:[~2023-05-25 10:15 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
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 [this message]
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=87y1lclnui.fsf@gnu.org \
--to=jemarch@gnu.org \
--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=mcr+ietf@sandelman.ca \
--cc=sureshk@cisco.com \
--cc=void@manifault.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.