For cilium/cilium#11014, we're looking for a safe and fast way to make decisions in the Cilium code around (BPF-related) kernel features. Currently, we rely on bpftool for some things, some Cilium-specific code for others, but we'd prefer if this would be abstracted and unified to make things clearer. We've informally discussed this topic before, but I'm looking to open the conversation here so we can gather some more data to make an informed decision about the way forward.

Some implementation/design ideas below:

Errors

@lmb suggested we don't explicitly expose a 'features' API, but that the caller rely on errors being returned from particular library features. For example, a (hypothetical) Map.IterateBatch() would return a NotSupportedError when the kernel doesn't support map batch operations.

Package Variables

Exporting current have... variables (e.g. ebpf.HaveNestedMaps). This would hugely inflate the package's API surface; not ideal.

Features Struct

ebpf.Features() returning a struct containing bools:

type KernelFeatures {
  NestedMaps bool
  MapMutabilityModifiers bool
  etc ...
}

The struct can easily be appended to as new features are added, and will not cause breakage. Tests can be deprecated over time if they no longer prove useful.

Doesn't inflate the package API surface.

This option would allow Cilium to include a quick overview of supported kernel features in debug/status output. I remember someone internally voicing a need for this, though not sure who did.

Another conversation topic is whether or not we want to continue maintaining these feature tests going forward. What is the maintenance burden of the tests currently in the library? Once written, do they need to be extended or modified?