Add functions to check ABI of eBPF collection
It's useful to do some basic checks on a Collection if there is a user space component. Basically, let the user specific a list of MapSpec and make sure that they are present in the collection and have the right types. The same goes for ProgramSpec.
Open question: how to do this for pinned collections? In that case we do not have *Spec to work with.
I think if the user wants it they need to give an additional path to save metadata to (I know that the bpffs supports this in later kernels, but it would probably be good to have something backwards compatible to avoid confusion).
Let's get some unsupported errors going for some of these syscalls.
The only bit of the ABI that relies on syscalls being available are the LoadPinned* functions. I'll add some code which returns not supported.
@nathanjsweet I see these options, my preferred solution last:
- Add another feature test for the object info syscall, return ErrNotSupported from LoadPinned* if they don't work. Kind of involved, another feature test.
- Look at err, and decorate it if it is EINVAL. We can't know for sure that means the syscall isn't supported, since there are other things that might return this code.
- Document on LoadPinned* that kernel 4.13 is required (I think this is already the case) and that EINVAL can mean that your kernel is too old.
Thoughts?
Bump, @nathanjsweet can you clarify what you'd like to see?
I think potentially we could try to figure out kernel versioning inside the code and return good errors that explain when a feature cannot be used. I think a lot of folks who will use this library (including myself) might not be able to upgrade their kernel's rapidly and in the course of building new features might have a tough time sorting which features they can use or can't.
Potentially I could even see trying to make this a build-tag thing. If we had a good gencode file that could detect the kernel version we could potentially pass that tag through to the build and disallow certain functions from even being available for specific builds. One thing we need in all of this is a good matrix of features to kernel versions. This is something I can try to work on.
I'll keep thinking about this more.