[DTrace-devel] [PATCH 5/5 v2] Add a profile provider

[Eugene Loh]

Perhaps I could have written that last email more succinctly as follows.

I think the provider-specific probe_info() and attach() functions should 
not have "const" on their "prp" arguments.  Here is why.

We want DTrace to support a wide range of providers.  Hence, we supply a 
few provider-specific functions.

To date, our providers have been "tracepoint-like".  Specifically, 
probe_info() has read /sys/kernel/debug/tracing/$group/$event/format to 
get an event_id and read arguments;  it has also created a kprobe or 
uprobe if necessary.  We have discussed an attach() function, which 
would take a prp->event_id, run perf_event_open(), and store a 
prp->event_fd.

To support more general providers, we have discussed hiding 
provider-specific arguments such as event_id and event_fd behind a 
provider-specific, opaque pointer within prp.  So, I am suggesting that 
the prp argument to probe_info() and attach() should not be "const".

1)  If probe_info() for tracepoint-like providers will determine the 
event_id (possibly even creating a kprobe or a uprobe) and store it, but 
other providers do not even have an event_id at all, then the 
provider-specific probe_info() must access and update the prp opaque 
pointer.

2)  If attach() will "create probes" -- perhaps running 
perf_event_open() and attaching BPF programs to one or more file 
descriptors that we would like to associate with prp -- and the details 
are provider-specific, then the file descriptor(s) should also be stored 
using the provider-specific opaque prp pointer within the attach() function.

Still not short, but hopefully helpful.