Re: [Bpf] IETF BPF working group draft charter

["Jose E. Marchesi" <[e-mail]>]

> Jose E. Marchesi <[e-mail]> 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