RE: [PATCH 10/17] hyper-v: trace vmbus_open()

[KY Srinivasan]

> -----Original Message-----
> From: devel [mailto:driverdev-devel-bounces@xxxxxxxxxxxxxxxxxxxxxx] On
> Behalf Of Steven Rostedt
> Sent: Tuesday, October 31, 2017 6:10 AM
> To: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
> Cc: olaf@xxxxxxxxx; Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>;
> jasowang@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx;
> marcelo.cerri@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; Vitaly
> Kuznetsov <vkuznets@xxxxxxxxxx>; leann.ogasawara@xxxxxxxxxxxxx
> Subject: Re: [PATCH 10/17] hyper-v: trace vmbus_open()
> 
> On Tue, 31 Oct 2017 13:48:00 +0100
> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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.

Regards,

K. Y
> 
> -- Steve
> _______________________________________________
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxx
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdriverd
> ev.linuxdriverproject.org%2Fmailman%2Flistinfo%2Fdriverdev-
> devel&data=02%7C01%7Ckys%40microsoft.com%7C93ac7eb43f9745d3ba5f0
> 8d52060c8a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364505
> 22419439104&sdata=XT46EGhjw9yoenE8qrW0aTqfDJ0ONvAPPzFri4Udn%2BY
> %3D&reserved=0