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/tool...
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.