On 2022/8/17 18:14, Quentin Monnet wrote:
On 16/08/2022 16:17, Wei Yongjun wrote:
Currently, only one command is supported
bpftool trace pin <bpf_prog.o> <path>
It will pin the trace bpf program in the object file <bpf_prog.o>
to the <path> where <path> should be on a bpffs mount.
For example,
$ bpftool trace pin ./mtd_mchp23k256.o /sys/fs/bpf/mchp23k256
The implementation a BPF based backend for mockup mchp23k256 mtd
SPI device.
Signed-off-by: Wei Yongjun <weiyongjun1@xxxxxxxxxx>
Thanks a lot for the patch.
However, I don't think it's a good idea to add the new "trace" command
just for loading/attaching/pinning tracepoints programs. Instead I see
two possible approaches.
The first would be to extend support for program attachment. Bpftool is
already able to load programs including tracepoints via "bpftool prog
load", and it is able to attach some of them via "bpftool
prog/net/cgroup attach". We don't support attaching tracing-related
programs because at the time, BPF links didn't exist so we couldn't keep
the programs running after bpftool exited, and after links were created
nobody implemented it.
So I would prefer that we extend this, by making bpftool able to attach
(and pin the link for) tracing-related programs. Not necessarily just
tracepoints by the way, it would be nice to have support for kprobes
too. This could be by extending "bpftool prog attach" or creating
"bpftool perf attach" ("bpftool perf" already focuses on tracing
programs, so no need to add a new "trace" subcommand).
Thanks for your suggestion. I tried to make sense of what you mean.
With the first approach , we can attach program with following commands:
$ bpftool prog load smbus-xfer-default.o /sys/fs/bpf/testprog
$ bpftool prog
302: raw_tracepoint_writable name smbus_xfer_default tag
90c6bea70fef5b14 gpl
loaded_at 2022-08-17T14:17:44+0000 uid 0
xlated 816B not jited memlock 4096B map_ids 296,294,297
btf_id 500
$ bpftool perf attach id 302 spi_transfer_writeable /sys/fs/bpf/tplink
Note: spi_transfer_writeable is the name of tracepoint
Second approach: I realise that the above adds a constraint, because if
we attach a program that was already loaded, we can't get the attach
point from the section name in the ELF file, we need to pass it on the
command line instead. I understand the desire for a one-step
load-attach-pin_link, but with your new subcommand it would ignore all
the work we've done on "bpftool prog load": support loading multiple
programs from an ELF file, for reusing or pinning the maps, etc. So I
would rather extend the existing "bpftool prog load(_all)" with a new
keyword to tell bpftool to attach and create the link(s), if possible
(when all relevant info for attaching is present in the ELF file), after
loading the program(s).
Or add new keyword like 'pintp' to do one-step load-attach-pin_link:
$ bpftool prog load smbus-xfer-default.o /sys/fs/bpf/testprog pintp
and
$ bpftool prog loadall smbus-xfer-default.o /sys/fs/bpf/testprog pintp
I'd really have the first approach in bpftool at some point, I haven't
found the time to look into it just yet. The second one is probably
closer to what you're looking to achieve, and would be nice to have as
well. What do you think?
I will try to create the "bpftool perf attach" approach, if you agree
with it.
Thanks,
Wei Yongjun
