Re: [PATCH bpf-next v2] bpftool: implement perf attach command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 27 Aug 2022 at 06:12, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Fri, Aug 26, 2022 at 3:45 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
> >
> > Hi Andrii,
> >
> > On 25/08/2022 19:37, Andrii Nakryiko wrote:
> > > On Thu, Aug 25, 2022 at 8:28 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
> > >>
> > >> Hi Wei,
> > >>
> > >> Apologies for failing to answer to your previous email and for the delay
> > >> on this one, I just found out GMail had classified them as spam :(.
> > >>
> > >> So as for your last message, yes: your understanding of my previous
> > >> answer was correct. Thanks for the patch below! Some comments inline.
> > >>
> > >
> > > Do we really want to add such a specific command to bpftool that would
> > > attach BPF object files with programs of only RAW_TRACEPOINT and
> > > RAW_TRACEPOINT_WRITABLE type?
> > >
> > > I could understand if we added something that would be equivalent of
> > > BPF skeleton's auto-attach method. That would make sense in some
> > > contexts, especially for some quick testing and validation, to avoid
> > > writing (a rather simple) user-space loading code.
> >
> > Do you mean loading and attaching in a single step, or keeping the
> > possibility to load first as in the current proposal?
> >
> > >
> > > But "perf attach" for raw_tp programs only? Seem way too limited and
> > > specific, just adding bloat to bpftool, IMO.
> >
> > We already support attaching some kinds of program types through
> > "prog|cgroup|net attach". Here I thought we could add support for other
> > types as a follow-up, but thinking again, you're probably right, it
> > would be best if all the types were supported from the start. Wei, have
> > you looked into how much work it would be to add support for
> > tracepoints, k(ret)probes, u(ret)probes as well? The code should be
> > mostly identical?
>
> Are you thinking to allow to attach individual BPF programs within BPF
> object, i.e., effectively bpftool as an interface to libbpf's
> bpf_program__attach()?
>
> Or you had more of BPF skeleton's auto-attach that attaches all
> auto-attachable BPF programs?

Here I was thinking the former, to have the support for tracing
programs catch up with networking/cgroup programs that can be attached
with bpftool already.

Although for the future I'm also considering the second option, where
we could pass an option to "bpftool prog load" to tell it to attach
everything it can. Not sure yet, there are some similarities between
the two (and my guess is you would find it too much?), but they're not
exactly the same use case either.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux