From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756644AbdKDLFb (ORCPT ); Sat, 4 Nov 2017 07:05:31 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38772 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752482AbdKDLF3 (ORCPT ); Sat, 4 Nov 2017 07:05:29 -0400 Date: Sat, 4 Nov 2017 12:05:20 +0100 From: Greg KH To: KY Srinivasan Cc: Steven Rostedt , "olaf@aepfle.de" , Stephen Hemminger , "jasowang@redhat.com" , "linux-kernel@vger.kernel.org" , "apw@canonical.com" , "marcelo.cerri@canonical.com" , "devel@linuxdriverproject.org" , Vitaly Kuznetsov , "leann.ogasawara@canonical.com" Subject: Re: [PATCH 10/17] hyper-v: trace vmbus_open() Message-ID: <20171104110520.GA425@kroah.com> References: <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> <20171031091028.7fa53a97@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 01, 2017 at 05:43:08PM +0000, KY Srinivasan wrote: > > > > -----Original Message----- > > From: devel [mailto:driverdev-devel-bounces@linuxdriverproject.org] On > > Behalf Of Steven Rostedt > > Sent: Tuesday, October 31, 2017 6:10 AM > > To: Greg KH > > Cc: olaf@aepfle.de; Stephen Hemminger ; > > jasowang@redhat.com; linux-kernel@vger.kernel.org; apw@canonical.com; > > marcelo.cerri@canonical.com; devel@linuxdriverproject.org; Vitaly > > Kuznetsov ; leann.ogasawara@canonical.com > > Subject: Re: [PATCH 10/17] hyper-v: trace vmbus_open() > > > > 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. > > Greg, > > The added memory overhead is very minimal, and the added tracing support is extremely useful for > our debugging. If you don't mind, I would like to have this tracing support. Ok, it's your subsystem, you get to handle the long-term maintenance of these :) Now merged, greg k-h