> Jose E. Marchesi <jemarch@xxxxxxx> 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
