On Fri, Jan 21, 2022 at 10:20 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > 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. ... but I don't find it confusing and no one really ever complained?.. So it doesn't seem like we need to remove this.
