From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753107AbdJaNKe (ORCPT ); Tue, 31 Oct 2017 09:10:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:49518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbdJaNKc (ORCPT ); Tue, 31 Oct 2017 09:10:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B1E421903 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 31 Oct 2017 09:10:28 -0400 From: Steven Rostedt To: Greg KH Cc: olaf@aepfle.de, sthemmin@microsoft.com, jasowang@redhat.com, linux-kernel@vger.kernel.org, marcelo.cerri@canonical.com, apw@canonical.com, devel@linuxdriverproject.org, Vitaly Kuznetsov , leann.ogasawara@canonical.com Subject: Re: [PATCH 10/17] hyper-v: trace vmbus_open() Message-ID: <20171031091028.7fa53a97@gandalf.local.home> In-Reply-To: <20171031124800.GA27947@kroah.com> References: <20171029192030.12356-1-kys@exchange.microsoft.com> <20171029192116.12466-1-kys@exchange.microsoft.com> <20171029192116.12466-10-kys@exchange.microsoft.com> <20171029205958.GA30187@kroah.com> <877evdyrsc.fsf@vitty.brq.redhat.com> <20171030084537.GA14865@kroah.com> <873761ymnu.fsf@vitty.brq.redhat.com> <20171030103220.GA30988@kroah.com> <20171030103134.22086c4e@gandalf.local.home> <20171031124800.GA27947@kroah.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 31 Oct 2017 13:48:00 +0100 Greg KH wrote: > > I don't see how that information can be extracted easily without a > > tracepoint here. Am I missing something? > > Wasn't one of the outcomes of the conference last week the fact that for > ftrace + ebpf we could get access to the structures of the function > parameters? Or that work would soon be showing up? I told Linus that I'll start building an infrastructure on function tracing to see what we can do. But it may be very limited in features. I don't believe eBPF can follow arbitrary data structure pointers without helper functions. Which doesn't exist for this type of code yet. > > It just feels "wrong" to add a tracepoint for a function call, like it > is a duplication of work/functionality we already have. We don't already have it. We may have something in a year (or two) that may be able to get all the data that is requested here. But it's going to take lots of RFC patch sets and brain storming to come up with something that everyone is satisfied with. In other words, the functionality is currently in vaporware state. -- Steve