Add proposal for ABI compatible bpf() emulation #3898
Conversation
lmb
requested review from
dthaler,
poornagmsft,
Alan-Jowett,
saxena-anurag,
shankarseal,
dv-msft,
gtrevi,
shpalani,
matthewige,
mtfriesen and
rectified95
as code owners
|
|
||
| ### Differing `bpf_cmd_id` values | ||
|
|
||
| The values of `bpf_cmd_id` do not match Linux, which leads to ebpf-go performing the wrong syscalls. |
There was a problem hiding this comment.
Only if you used the Linux rather than the Windows BTF data, no? If ebpf-go for Windows is generated from Windows BTF why would it perform the wrong syscalls?
docs/BpfSyscallCompatibility.md
Outdated
| ``` | ||
|
|
||
| This is problematic because Linux exposes many more fields in `bpf_map_info`, aliasing with the Windows-specific fields. | ||
| Adding a new cross-platform field before the Windows-specific fields will break API compatibility, adding it at the end will cause ABI break with Linux's defininition instead. |
There was a problem hiding this comment.
I get that it's not ABI compatible, but why will it break "API" compatibility? (which to me means source level)
There was a problem hiding this comment.
Yeah these terms are confusing.
My mental model of efW compatibility is currently that if you compile against your headers, binaries should continue to work with new versions of the runtime (otherwise the discussion of changing bpf_cmd_id etc. becomes moot.) This model breaks when adding a new cross-platform field, since the old binary will interpret it as inner_map_id.
|
Something that would be useful to know: what projects or code currently relies on the |
|
@shankarseal can we please discuss this during the next office hours on Monday 2024-10-21? @dthaler did my comments make sense to you? What do you think of the current proposal? |
|
Added a link and changed the wording to reflect what we discussed in the last triage meeting. |
As discussed during this weeks triage meeting, I've written up my considerations of how I can do a port of
ebpf-goto Windows.Updates #3729