> -----Original Message----- > From: Dave Thaler <dthaler@xxxxxxxxxxxxx> > Sent: Monday, August 8, 2022 11:54 AM > To: bpf@xxxxxxxxxxxxxxx > Subject: Followup from LSF/MM/BPF on standardization/documentation > > At LSF/MM/BPF, the topic was raised about better documenting eBPF and > making "standards" like documentation, especially since we are having > runtimes other than just Linux now supporting eBPF. And ideally hosting it > under the eBPF Foundation. > > I'd like to use this week's BPF office hours slot (Thursday 9am Pacific) to kick off > a discussion of this topic, so wanted to send this email to invite anyone > interested in contributing to such an effort. Hopefully we can discuss how to > organize the effort and some principles we might use for what might be in > scope. > > Dave FYI, below are today's notes from Daniel Havey... Dave ----- Interests: o Dave Tucker: maintain rust libs for bpf. - Lots of questions about basic things. Not covered anywhere centralized. > Want to put into kernel documentation o Christoph:In the NVMean computatianal storage - Able to execute programs on a storage device where you have NVME and run them on that device. > eBPF as the binary format for these downloadable programs. > No cannonical spec for eBPF - Is a girhub repo sufficient? > Maybe, a website is preferred - snapshot of pdf > Just need a stable reference > Under eBPF.io o Jim: User space NVME drivers - Agree with the above o Dave Thaler: Microsoft eBPF architect - Cross-platform - how do we keep track of the different run times - Not diverge - coordinate Questions: o Christoph - verifier, what is in the classic instruction set. Intricate interaction - Yes, verifier expectations exists as a starting point - Linux kernel and Prevail > Uses of uBPF which do not use a verifier Scope and Organization o Cross-plat or Linux or in-between o Might be cross-impl vs run-time specific (version specific) o Something limited to a single platform or imple - Does this effort care? o When does it become standard? o Impl or OS specific will get complicated o Interest in generic run-time specification o NVME perspective - certain eBPF op-codes Linux specific - How does this get impled in the spec? o Impl specific opcodes are a slippery slope. - Will get us in trouble. > Avoid going forward. > Let's not make room for vendor specific stuff up front. o Is there a use case for impl specific? o Decide on the subset of eBPF stuff that is compat amongst runtimes and document stuff that is divergent and call it out. - Hashmaps will likely behave differently anyways o To be portable you cannot depend on details of things like what types of hash is used in a hashmap o However, functionality should be cross-runtime o Abstract concept should be documented - How they are constructed without impl details - Too much impl detail is baaad. o Subset of the Linux API and make it a standard? - All of this sounds like a subset of the Linux API? How do we deal with things that vary? o Capability variation - Multiple versioning - Language that is MUST/SHPOUL/MAY - Manditory an optional or conditionaly manditory o How to define and split up the run time? - Hashmaps - part of the program type? - Instruction set - bare minimum and extensions - Extensibility by naming extensions and having a bitmap - For runtimes - program types. environments that support everying that is minimum and optional o Let's just use MUST/SHOULD/MAY and multiple versions Components in scope: o Initial in-scope too big to be practical - Remove everything except ISA > Prog types in Linux that nobody is using - don't standardize on them - Need instruction set in the ELF format - Verifier expection - exceptions, etc. - What is the job of the verifier vs the runtime - NVME doesn't need as much verification > How much verification is the min? > X86 hardware has a built in verifier. - Kindof verifiers - Some core aspects of verifier make BPF powerfull > For instance: safety - This can be static or dynmic - Probably a MAY - uBPF doesn't have a verifier because probably everything in there is safe? > Or unsafe depending on your viewpoint. - Abstract - mention that there are maps, programs and helpers? > What is eBPF doc. Should this be official doc? - Standardize the parts of ELF format and BTF(?) because the instr set alone is not suffiecient > BTF carries some of the info for the prog to be accepted by the verifier. - Can't document the ELF format without talking about BTF > Could be a SHOULD feature - You can have an ELF file with nothing in it. - FE relocation - should be captured in the spec > BTF can describe variable nature of an NVME command > Instead of raw bytes using BTF to describe might be more flexible - We don't need it initally - On Windows side: No support for BTF except for debugging purposes - Debug info for reporting errors may be useful for NVME - Good to have BTF so people don't start inventing their own thing. - BTF is a low level format that is portable and easily well-described - Load time, meta data - Run time verifications that are not captured should be described by BTF o Compilers - are they in scope? Do we describe what the compiler should do? - This probably boils down to details. - What is in-scope, but not covered here - ISA, ELF, BTF and low-level should be very clear what is expected from compiliers - Are we going to write code to verify that you have complied? > Yes, we should do this. - Verifier should be what is checking that the prog is compling > A verifier test suite - Compliance of a BPF program not of a runtime - Stay at the self-test level > If some parts are interchangeable between runtimes great, but don't try too hard for this - Is this a valid BPF opcode, is it handled properly, etc? > Syntactic correctness, can be executed independently of the platform. - Take all the progs offline and dump them into the oracle to see if they are all doing the same things > KP Singh - Yes, I can write this. > uBPF can be the basis of this - Impl JITs - set of values that you load, do some ops and compare the output - Give examples in the doc. How do we org this effort? o PRs and meetings if needed - use office hours Current doc - most cannocal source of truth is the kernel repo o Do we move the source of truth? o The source of truth for Linux and the souce of truth for cross-plat are different. We should move it so that there is only one. o Are there legal issues with this idea? Don't move it, keep it in the kernel tree o Keeping in the Linux is a barrier for non-Linux peeps o Github is a barrier also. o License is a real objection. o We must spec license X (MIT?) o License is not a strong enough reason to move from kernel to github o PDF document somewhere in the eBPF foundation - How does this work? - Do we snap when we have a version and post it? - Host release doc at the foundation. o Need another ad-hoc meeting to keep discussing - Something cannonical must appear on the Foundation website Do we need a mailing list? o Can we use the existing BPF list? a) Use the list b) Use the list with magic tag? <-- This one (bpf-doc) c) Use another list.
