> Hi David, > I just want to provide a quick clarification from the IETF side > regarding categories of RFCs. Not all the RFCs we produce are > standards. On a broad level we have standards track and informational > documents (among others; more details in RFC2026). I do believe there > is value in *documenting* some of the items that belong in an ABI such > as the calling convention (similar to what is in Section 2 of the ISA > draft). Similarly, there is value in documenting conventions and > guidelines for creating portable binaries if we believe that is a > useful goal, even though there will be a lot of programs that will not > be portable (e.g. using cgroups). I would not expect these to be > Standards track documents but rather Informational specifications to > help implementers. If that sounds reasonable we can keep the text in > the charter (with some minor rewording) and work on categorizing > potential deliverables by Document Status (as would anyway be > necessitated by Éric Vyncke’s BLOCK). 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. Could then the WG edit and publish "snapshots" whenever considered appropriate, and release them as subsequent versions of an IETF Informational specification, or some other suitable kind of IETF document? If something like that would be doable, maybe we could concile the practicality of the usual approach with the more formal character of an IETF document? > Regards > Suresh > >> On May 23, 2023, at 4:28 PM, David Vernet <void@xxxxxxxxxxxxx> wrote: >> >> On Tue, May 23, 2023 at 01:58:18PM -0400, Michael Richardson wrote: >>> >>> David Vernet <void@xxxxxxxxxxxxx <mailto:void@xxxxxxxxxxxxx>> wrote: >>>> 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 >>> >>> All of the eBPF work seems unprecedented. >>> I don't see having this in the charter is a problem. >>> >>> We may fail to get consensus on it, and not make a milestone, but I don't see >>> a reason not to be allowed to talk about this. >>> (and maybe in the end, it's a no-op) >> >> Hi Michael, >> >> So apologies in advance if my lack of experience with IETF proceedings >> is glaringly obvious, and I'd appreciate clarification in any situation >> in which I'm mistaken. >> >> My understanding based on the conversations that I've had thus far is >> that part of the goal of arriving at the finalized WG charter is to >> determine what's in scope and out of scope. It's a bit of a murky >> proposition because some things that we think _could_ be in scope, such >> as in this case topics related to psABI, may not end up having a >> document if we can't get consensus. In other words, being in the WG >> charter doesn't imply that something is in-scope and will have a >> document written, but _not_ being in the charter does preclude it from >> being discussed in this iteration of the WG because of this line: >> >>> The working group shall not adopt new work until these >>> documents have progressed to working group last call. >> >> The implication of this is that it's not necessarily a problem to have >> some false-positives in terms of what we cover, but it can be >> problematic if we leave out something important because we'll have to >> cover all of the other topics first. I'd imagine this would tend to make >> the default behavior for deciding scope in WG charters to be permissive >> rather than dissmive, which makes sense to me. >> >> Assuming I haven't already gone off the rails in terms of my >> understanding, let me try to clarify why despite all that, I still think >> it's warranted for us to remove psABI as part of the scope of the WG. >> There are really two main reasons: >> >> 1. As is hopefully clear at this point, there is a wide and historical >> industry precedence for not standardizing on psABI. For example, to >> my knowledge, RISC-V [0] develops and ratifies the RISC-V ISA through >> the RISC-V International Technical Working Groups, but there is no >> such ratified standard or specification for RISC-V calling >> conventions (the operative word of course being "convention"). The >> same is true (to my knowledge) of _all_ psABI ELF extensions, as Jose >> pointed out earlier in the conversation. >> >> [0]: https://riscv.org/technical/specifications/ <https://riscv.org/technical/specifications/> >> >> With all that said, unless there's more context behind why we think we >> need to standardize psABI which hasn't yet been brought forward, I >> don't see any way we'd achieve consensus when we discuss it in the >> WG. And the reason I specifically think that's the case for ABI (ELF >> or otherwise) is that there's such a well-established precedence >> already for not standardizing it. I guess it's true that there's no >> harm in including it and discussing it, but as things currently >> stand, it also doesn't seem very productive to include it if there's >> already (IMHO) reasonably clear evidence that it's out of scope. To >> go back to my claim made in another email, I think the onus is on the >> folks who think it's in scope to explain why, rather than the folks >> who think we should follow industry precedence to justify that. >> >> 2. Assuming that I'm wrong, and ABI / ELF are in scope for >> standardization, we would still have to do a lot of premliminary >> work to determine that. For example, we may end up wanting to >> standardize that maps are put into .maps sections in an ELF file, but >> that would only make sense if we created a document standardizing >> cross-platform map types. The same holds true for cross-platform >> program types, etc. The dependency DAG for discussing ELF has a depth >> of at least 2, and given that it's as-yet unclear whether ELF / psABI >> is an appropriate topic for standardization in the first place, it >> really feels to me like leaving it out of the WG is the right move. >> >> Thanks, >> David >> >>> >>> -- >>> Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >>> >> >> >> >>> -- >>> Bpf mailing list >>> Bpf@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/bpf >> >> -- >> Bpf mailing list >> Bpf@xxxxxxxx <mailto:Bpf@xxxxxxxx> >> https://www.ietf.org/mailman/listinfo/bpf <https://www.ietf.org/mailman/listinfo/bpf>
