Jose E. Marchesi wrote: > As I mentioned during your talk at LSF/MM/BPF, I think that two items may be > a bit confusing, and worth to clarify: > > * the eBPF bindings for the ELF executable file format, > > What does "eBPF bindings" mean in this context? I think there are at least two > possible interpretations: > > 1) The way BPF uses ELF, not impacting internal ELF structures. For > example the special section names that a conformant BPF loader > expects and understands, such as ".probes", or rules on how to use > the symbols visibility, or how notes are used (if they are used) etc > > 2) The ELF extensions that BPF introduces (and may introduce at some > point) as an architecture, such as machine number, section types, > special section indices, segment types, relocation types, symbol > types, symbol bindings, additional section and segment flags, file > flags, and perhaps structures of the contents of some special > sections. See https://www.ietf.org/archive/id/draft-thaler-bpf-elf-00.html It includes the values used in the ELF header, section naming, use of the "license" and "version" sections, meaning of "maps" and ".maps" sections, etc. > If the intended meaning of that point in the draft is 1), then I would suggest to > change the wording to something like: > > * the requirements and expectations that ELF files shall fulfill so they > can be handled by conformant eBPF implementations. My own opinion is to leave the more detailed definition of what belongs in the ELF spec vs another document up to the WG to define rather than baking it into the charter. > Otherwise, if the intended meaning in the draft charter is to cover 2), I would > like to note that, usually and conventionally ELF extensions introduced by > architectures (and operating systems in the ELF sense) > are: > > - Part of the psABI (chapter Object Files). > > - Not standards, in the sense that these are not handled by > standardization bodies. > > - Maintained by corporations, associations, and/or community groups, and > published in one form or another. A few examples of both arch and os > extensions: > > + The x86_64 psABI, including the ELF bits, is maintained by Intel > (mainly by HJ Lu, a toolchain hacker) and available in a git repo in > gitlab [1]. > > + The risc-v psABI, including the ELF bits, is maintained by I believe > RISC-V International and the community, and is available in a git > repo in github [2]. > > + The GNU extensions to the gABI, including the ELF bits, is > maintained by GNU hackers and available in a git repo in sourceware > [3]. > > + The llvm extensions to ELF, which in this case take the form of an > "os" in the ELF sense even if it is not an operating system, are > maintained by the LLVM project and available in the > docs/Extensions.rst file in the llvm source distribution. > > Note that more often than not this is kept quite informally, without > the need of much bureocratic overhead. A git repo in github or the > like, maintained by the eBPF foundation or similar, would be more than > enough IMO. To ensure interoperability, I'd want a slightly more formal specification. > - 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 :/) There's 3 ways: 1) The IETF can publish an extension spec with additional optional features. 2) The IETF can publish a replacement to the original (not usually desirable) 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. Dave > Likewise, of the following item: > > * the platform support ABI, including calling convention, linker > requirements, and relocations, > > The calling convention and relocations are part of the psABI and usually > handled like described above. > > PS: BPF is obviously not a SysV system, but when it comes to document > the ABI, including the ELF bits, I think it would be a good idea to > use the same document structure conventionally used by psABI, as > Alexei already suggested some time ago. This would be most familiar > to people. > > [1] > https://gitlab/. > com%2Fx86-psABIs%2Fx86-64- > ABI&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f514d > 08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6381 > 99331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sd > ata=SaprU2J9WsyJ5qhcxIGKO2F06YtO%2Bm1Gpjb2SIOApLA%3D&reserved=0 > [2] > https://github/ > .com%2Friscv-non-isa%2Friscv-elf-psabi- > doc%2Freleases%2Fdownload%2Fv1.0%2Friscv- > abi.pdf&data=05%7C01%7Cdthaler%40microsoft.com%7Cd4f2ef78d9e0475f5 > 14d08db56e91312%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 > 38199331900533629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C > &sdata=uKqnU93kcu8rZ9Y0gzWdmuHnK9ySPM847%2FDMm6vJNwQ%3D&res > erved=0 > [3] git://sourceware.org/git/gnu-gabi.git > > -- > Bpf mailing list > Bpf@xxxxxxxx > https://www.i/ > etf.org%2Fmailman%2Flistinfo%2Fbpf&data=05%7C01%7Cdthaler%40microso > ft.com%7Cd4f2ef78d9e0475f514d08db56e91312%7C72f988bf86f141af91ab2 > d7cd011db47%7C1%7C0%7C638199331900533629%7CUnknown%7CTWFpb > GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > Mn0%3D%7C2000%7C%7C%7C&sdata=W9FXcUwb181VQ6ksF2guASQ5FGtTE > KZuE0Yb8cHR9vI%3D&reserved=0
