On Fri, Jan 21, 2022 at 10:15 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Thu, Jan 20, 2022 at 5:44 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Thu, Jan 20, 2022 at 3:43 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > > > > > This patch series is a refinement of the RFC patchset [1], focusing > > > on support for attach by name for uprobes and uretprobes. Still > > > marked RFC as there are unresolved questions. > > > > > > Currently attach for such probes is done by determining the offset > > > manually, so the aim is to try and mimic the simplicity of kprobe > > > attach, making use of uprobe opts to specify a name string. > > > > > > uprobe attach is done by specifying a binary path, a pid (where > > > 0 means "this process" and -1 means "all processes") and an > > > offset. Here a 'func_name' option is added to 'struct uprobe_opts' > > > and that name is searched for in symbol tables. If the binary > > > is a program, relative offset calcuation must be done to the > > > symbol address as described in [2]. > > > > I think the pid discussion here and in the patches only causes > > confusion. I think it's best to remove pid from the api. > > It's already part of the uprobe API in libbpf > (bpf_program__attach_uprobe), but nothing really changes there. > API-wise Alan just added an optional func_name option. I think it > makes sense overall. Technically it can be deprecated. So "it's already part of api" isn't really an excuse to keep confusing the users.
