On 11/07, Jakub Kicinski wrote: > On Wed, 7 Nov 2018 15:34:48 -0800, Stanislav Fomichev wrote: > > On 11/07, Jakub Kicinski wrote: > > > On Wed, 7 Nov 2018 15:13:33 -0800, Stanislav Fomichev wrote: > > > > On 11/07, Jakub Kicinski wrote: > > > > > On Wed, 7 Nov 2018 14:43:56 -0800, Stanislav Fomichev wrote: > > > > > > bpftool map update pinned /sys/fs/bpf/flow/jmp_table \ > > > > > > key 0 0 0 0 \ > > > > > > value pinned /sys/fs/bpf/flow/IP/0 > > > > > > > > > > Where is that /0 coming from ? Is that in source code? I don't see > > > > > libbpf adding it, maybe I'm missing something. > > > > libbpf adds that, that's a program instance: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/bpf/libbpf.c#n1744 > > > > > > Ugh, I was looking at bpf_object__pin() which uses names :( > > > > > > We never use this multi-instance thing, and I don't think bpftool ever > > > will, so IMHO it'd be good if we just re-did the pinning loop in > > > bpftool. > > I wonder whether I should just add special case to bpf_program__pin: don't > > create a subdir when instances.nr == 1 (and just create a file pin for > > single instance)? In that case I can continue to use libbpf and don't reinvent > > the wheel. Any objections? > > Mm.. I'm afraid libbpf needs to keep backward compatibility. We'd have > to add some way for the user (bpftool code) to request the instance ID > does not appear, but (potential) existing users should keep seeing them. > Perhaps others disagree. AFAICT, nobody (seriously) uses bpf_object__pin in the kernel tree and I have a feeling that the situation is the same outside of the kernel tree. We can revert/work around if we break somebody, I just don't want to reimplement the same code in bpftool while there is a possibility that nobody is using that. I'll post my proposal as v3, let's see whether other people have the same objections. Btw, did we officially commit to the libbpf api/abi somewhere? It always felt to me like an internal and work-in-progress library.
