error when loading CollectionSpec with map definition has more than type, keysize, valuesize, maxentries, and flags fields about ebpf

[lmb]

Yeah, this is a problem. We've not had a use-case for .pinning or .namespace, so I've not implemented support for them. I suspect that they make little sense from the POV of the library, since you can easily achieve the same effect (with more flexibility) by using the API.

I don't want to just ignore these fields, since this would silently break users that rely on this feature, instead of giving them a starting point for an investigation.

Unless you think .pinning and .namespace should be supported I'll close this as "won't do".

[hamburgerbun]

hmm. i think it'd be nice to be able to read them if they're there for reference purposes, as if those fields were the suggested use case, but we definitely wouldn't want to act on them in the same automatic way as the others (for example, .pinning field, tc bpf loading would see the pinning field and immediately randomly generate bpf fs folder for non-global things and pin accordingly).

but i definitely wouldn't consider them essential in any way if using this module since we have nice control over pinning and stuff anyways. at best this would be an enhancement but unless somebody else brings up a similar complaint, it should probably just go into the "won't do" pile since my associate already dropped the fields in question in our map defs.

[lmb]

Makes sense. Feel free to reopen the issue if things change.