Re: [Bpf] IETF BPF working group draft charter

[David Vernet <void@manifault.com>]

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.