Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3130536pxb; Fri, 4 Feb 2022 01:54:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJxTmH9NAhjElmUp6mwd4PqZkyBknwZkpER76uzt6gpZpDSY6RNdSdjH4zg7c8h8C41l4YKO X-Received: by 2002:a63:451f:: with SMTP id s31mr1787014pga.114.1643968482359; Fri, 04 Feb 2022 01:54:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643968482; cv=none; d=google.com; s=arc-20160816; b=PzTXgOUGP7Rdgof7Xm68EeB11V30cf5Zutjfw5YzL0fn5ovWFBeEKlm9jASFU8QbZA Ldtg3d4UXiXvvLxshhOCySChRFkOgU1omhSs+xPE1KhgI6WfdmO5T8/OMrZ0An+LxTf7 oScsMqmL2dsHC4n5KDbNM2YZqUWcSiu4ncXyKX7/8LtzWXPFR8CBxw3QdYgDFI26UoEE qfuERj73K9Ibt/0vtyYEB95Kd22ymubswZ66My26Kj0Z4lUfdXUjvcKJhVl2ysYYea7I mm1vkGgHTgbrPr6hn+qp84CV+fb17Wd8VQfk81TIv3hkbzvV8LBYrbPEOzy2T7MmeMXB 9QOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Nb6/p4JpGyx/ZHKKnvpMEjRL+U8Fz5t1o+pJu4sqrqU=; b=E5f6pg5jaxAktNBA9K1pdJYk3ktyXbWWsAutBBYl8tdqkrmjjJsG5/Hvd76OEfQmtO S6RJtQOJ5l6QvM1/rDu49Bjp26Gl75mxIslhzU5OrQLgHZV5zmm+fxRXMjMODNm3Wd9O CL7CR7z1I/AqyLxU9Aw/axI35BE0eXTb04I6UyR7DDsHC4KHf4oC+GxiaD0/u7Ivd+Br d0ugiCKIJk+oBlYvVXb0OSwRN4L76sbH+jWt5wUBs3QlOn52ydArr0i4WXPymrkx27pj 1nux+2XNIJco6cY8hlNGPB2qttaUleZJPE/XD8CfRxCrVmR6YnezwTUZaltN6jeWhaaS ixow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y7si1392977plg.246.2022.02.04.01.54.28; Fri, 04 Feb 2022 01:54:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356631AbiBDCUA (ORCPT + 99 others); Thu, 3 Feb 2022 21:20:00 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48124 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234237AbiBDCT7 (ORCPT ); Thu, 3 Feb 2022 21:19:59 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8AD96B817E5; Fri, 4 Feb 2022 02:19:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE461C340E8; Fri, 4 Feb 2022 02:19:55 +0000 (UTC) Date: Thu, 3 Feb 2022 21:19:54 -0500 From: Steven Rostedt To: Alexei Starovoitov Cc: Masami Hiramatsu , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Network Development , bpf , lkml , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Jiri Olsa Subject: Re: [PATCH 0/8] bpf: Add fprobe link Message-ID: <20220203211954.67c20cd3@gandalf.local.home> In-Reply-To: References: <20220202135333.190761-1-jolsa@kernel.org> <20220204094619.2784e00c0b7359356458ca57@kernel.org> <20220204110704.7c6eaf43ff9c8f5fe9bf3179@kernel.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Feb 2022 18:12:11 -0800 Alexei Starovoitov wrote: > > No, fprobe is NOT kprobe on ftrace, kprobe on ftrace is already implemented > > transparently. > > Not true. > fprobe is nothing but _explicit_ kprobe on ftrace. > There was an implicit optimization for kprobe when ftrace > could be used. > All this new interface is doing is making it explicit. > So a new name is not warranted here. > > > from that viewpoint, fprobe and kprobe interface are similar but different. > > What is the difference? > I don't see it. IIUC, a kprobe on a function (or ftrace, aka fprobe) gives some extra abilities that a normal kprobe does not. Namely, "what is the function parameters?" You can only reliably get the parameters at function entry. Hence, by having a probe that is unique to functions as supposed to the middle of a function, makes sense to me. That is, the API can change. "Give me parameter X". That along with some BTF reading, could figure out how to get parameter X, and record that. -- Steve