Re: [Bpf] IETF BPF working group draft charter

["Jose E. Marchesi" <jemarch@gnu.org>]

> 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.