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

[Kris Van Hees]

On Sat, Jun 20, 2020 at 09:26:16AM -0700, Eugene Loh wrote:
> 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.

When provider-specific data (like event_id and event_fd) are stored in a
provider specific struct that is referenced through an opaque pointer in the
dt_probe_t structure, then const makes perfect sense for the functions in
the provider because those functions do not (and should not) modify the
data in the dt_probe_t structure.  All modifications are limited to the
provider specific struct that can validly be modified even when prp itself
is const.