On Tue, Feb 9, 2021 at 3:03 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Gilad Reti <gilad.reti@xxxxxxxxx> writes: > > >> > I didn't get this last comment. What I meant is that I want something > >> > like the bpf_object__pin_maps but that doesn't pin the maps, just > >> > exposing its naming part. > >> > >> Right, OK. Why, though? I can kinda see how it could be convenient to > >> (basically )make libbpf behave as if all maps has the 'pinning' > >> attribute set, for map reuse. But I'm not sure I can think any concrete > >> use cases where this would be needed. What's yours? > >> > > > > I am using the same bpf objects (more specifically, the new skeleton > > feature) in two different processes that need access to the same > > maps/programs (for example, they both need access to shared maps). > > Thus, I want to reuse the entire object in both. Since we already have > > a way to pin an entire bpf object, I thought it would be convenient to > > have a way of reusing it entirely (though I am fine with pinning and > > reusing each one manually). > > (I cannot set the __uint(pinning, LIBBPF_PIN_BY_NAME) on each since I > > want to share the bss map too) > > Ah, see, now *this* could go under the "missing API" header: having a > way to make libbpf pin (and reuse) the auto-generated maps, like you can > do with the 'pinning' attribute. > > Andrii, WDYT? I think that the whole pinning handling in libbpf feels a bit ad-hoc. It would be good for someone to sit and think through this end-to-end. Unfortunately I never had a need for pinning, so I'm not the best person to do this. In this case, you can still do bpf_map__set_pin_path() on internal maps (.bss, .data, etc), but you'll need to specify pin path explicitly, which is different from what you get with LIBBPF_PIN_BY_NAME. So I think pinning support is not complete, but I'd also like to avoid adding new APIs in an ad-hoc manner without a holistic view of how pinning should work with libbpf. > > -Toke >
