Jose E. Marchesi <jemarch@xxxxxxx> 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. > >> - Open to suggestions and contributions from the community, vendors, > >> implementors, etc. This usually involves having a mailing list where > >> such suggestions can be sent an discussed. Almost always very little > >> discussion is required, if any, because the proposed extension has > >> already been agreed and worked on by the involved parties: toolchains, > >> consumers, etc. > >> > >> - Continuously evolving. > >> > >> So, would the IETF working group be able to accomodate something like > >> the above? For example, once a document is officially published by > >> the working group, how easy is it to modify it and make a new version > >> to incorporate something new, like a new relocation type for example? > >> (Apologies for my total ignorance of IETF business :/) My point in the options is that a standard can be constructed such that adding a new codepoint does NOT require making a new version. That's the point of things like IANA registries. So yes it is straightforward to accommodate _without_ requiring a new version. One only requires a new version if there are actually errors in the original, or the original did not allow an IANA registry or other process for codepoint allocation. > > There's 3 ways: > > 1) The IETF can publish an extension spec with additional optional > > features. > > I don't think adding new relocation type, as an example of the kind of > changes that ABIs regularly are subjected to, qualify as "additional optional > features". I'm not familiar enough with existing ones to comment on those. > > 2) The IETF can publish a replacement to the original (not usually > > desirable) > > You _will_ need to update that particular document, and probably quite > often. I'm not convinced of that. Indeed that would be very unusual in the IETF. Rather the IETF has established patterns of writing documents that obviate the need to update any single document quite often. > jemarch@termi:~/gnu/src/x86-64-ABI$ git log --oneline --since="May 18 > 2022" > b96eaf2 (HEAD -> master, origin/master, origin/HEAD) Remove MPX > support > ab1bd26 _BitInt: Update alignment of _BitInt(N) for N > 64 > 43453ea Clarify R_X86_64_REX_GOTPCRELX transformation > e2387f1 Add link to download latest PDF > b5443bf Fix typo in footnote stating incorrect register range for AVX512 > 8195730 Add optional __bf16 support > 6c2ac6c ABI: Fix typos > 8ca4539 Add _BitInt(N) from ISO/IEC WG14 N2763 Going off of nothing but the text above: * Fixing typos: this is the job of the RFC editor pass to catch anything that was missed in the earlier steps. In theory there should be no typos in an RFC. In practice there is an errata process, but typos are not "often". * Links to download: Links in references inside the document should be to stable references. Links to IETF documents themselves often go to an info page which has links to the various formats of the document (html, pdf, etc.) along with links to any errata and IPR declarations. * Adding optional support for something: this is most typically done in a separate document, not by modifying the original. The point being that in the IETF processes, documents are updated but it is not "quite often", and the list you cited doesn't convince me that an IETF style document would need to be updated "quite often". > That is for a very well consolidated and stable architecture such as x86_64. > Now imagine what will happen with something like BPF that is still in the > process of figuring out its own ABI and the way it gets compiled. > > Being very optimistic, would it be OK for IETF and the WG to release, say ten > new versions of the "original" per year? My personal opinion: No, I'd consider that a failure of the document process of the WG if that happened. I can say I've been participating in the IETF since 1994 in many areas and WGs, published between 55 and 60 RFCs, and I've never seen anything that would have multiple new versions of the original per year. I don't expect anything in BPF to be more special than all the other things I've seen. But maybe it's just me :) > > 3) The IETF can define a process for other organizations or vendors to > > create their own extensions, and some mechanism for ensuring that two > > such extensions don't collide using the same codepoint. This is what > > the charter implies the WG should do. > > What is the precise license under which the document describing the ELF > extensions and the ABI will be distributed? > In particular, does it allow distributing modified versions? See https://datatracker.ietf.org/doc/html/rfc8721 in general, but specifically https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ section 3. Dave
