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.
