* RE: Followup from LSF/MM/BPF on standardization/documentation
2022-08-08 18:54 ` Followup from LSF/MM/BPF on standardization/documentation Dave Thaler
@ 2022-08-11 17:23 ` Dave Thaler
0 siblings, 0 replies; 5+ messages in thread
From: Dave Thaler @ 2022-08-11 17:23 UTC (permalink / raw)
To: bpf; +Cc: Daniel Havey
> -----Original Message-----
> From: Dave Thaler <dthaler@microsoft.com>
> Sent: Monday, August 8, 2022 11:54 AM
> To: bpf@vger.kernel.org
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread