As libbpf is heading towards a first major release, we wanted to discuss libbpf's object pinning strategy. bpf object pinning has a couple of use cases (feel free to add, there are more for sure): 1. Sharing specific bpf objects between different processes (for example, one process loads a bpf skeleton, another one interacts with it using various bpf maps (for example, for changing configurations (i.e. dynamic networking rules etc)) 2. Preventing bpf objects from destruction upon owning process exit (i.e. to prevent bpf progs detach upon userspace program crash) Regarding the first use case, for most cases manually setting the pin path (both in the loading process and in other processes) will probably be the best. In such cases, no redesign is required here. For the second one, something like the bpf_object__pin will be more appropriate (to allow a complete reuse of the bpf objects). For that use case, some sensible requirements we can consider are: 1. Paths should be unique: a. at the bpf_object level (that is, same pinnable objects that belong to different bpf_object s should be pinned at different paths). b. in the same bpf_object, between different pinnable object types (i.e. a map and a prog) should always be pinned at different paths. c. different objects, belonging to the same bpf_object and of the same type should be pinned at different paths. 2. Paths should be predictable, given enough information on the originating bpf_object (that is, adding random UID to ensure uniqueness is not an option). All the above should be applied to auto-pinned maps and the bpf_object__pin function. I am not sure if the bpf_object__pin_{maps,programs} should conform to those requirements too. Of course, all paths should be overridable similarly to the current implementation. Regarding implementation, 1.c. will already be satisfied by the current implementation (after the program name pinning path will be changed, since both map names and function names are unique inside a single object). For 1.a and 1.b, I think that bpf_object__pin should produce the following directory layout: <obj_name> ├── maps │ └── <map_name> └── programs └── <program_name> If we decide that the requirements should apply to the specific bpf_object__pin_<type>s variants, then each will produce <obj_name> └── <type>s (i.e. maps, programs) └── <name> It may be better to put all pinned objects under a objects/ directory too, I am not sure about that. As a last point, I think that it will be nice to have a way to pin a bpf_object_skeleton. This will be an improvement over the current bpf_object__pin since skeletons keep track of attached links. There are more use cases I am not familiar with for sure, so I would like to hear other's opinions and comments.