Only the PossibleCPU() changes, please.

The key/val change doesn't make much sense IMO.

• Changing the key or value size without the knowledge of the bpf program will result in the program potentially reading past the end of the value on kernels where the value is 4 bytes, resulting in a verifier error. In order to remain portable, an application (the Cilium agent, in this case) needs to target the lowest common denominator of any given feature. When support for older kernels is dropped, the 8-byte value can be used (should be fine for Cilium since we target 5.4+), unless the program is compiled specifically for the running kernel (which we're trying to get rid of in Cilium).

• Kernel versions are meaningless in bpf land; vendors (mostly RH) backport tons of features to older kernels, while disabling others for security reasons. Reacting to the availability of certain features must be done using probes, e.g. in this case by trying to create a map of a particular size. Tests are the only exception, since we use only mainline kernels and need some way of defining when a test needs to pass and when it can be skipped.

Also, for our purposes, a simple map creation test will do with a check on Map.MaxEntries(). Don't overthink it. 😉

Thanks!