[DTrace-devel] [PATCH 3/3] add BEGIN and END probes

Eugene Loh eugene.loh at oracle.com
Fri Apr 3 20:36:48 PDT 2020


On 04/02/2020 11:54 PM, Kris Van Hees wrote:

>>>>> On Fri, Mar 27, 2020 at 01:21:03AM -0400, eugene.loh at oracle.com wrote:
>>>>>> From: Eugene Loh <eugene.loh at oracle.com>
>>>>>>
>>>>>> Add BEGIN and END probes as uprobes on libdtrace functions
>>>>>> BEGIN_probe() and END_probe(), which were added as part of
>>>>>> an earlier patch.
>>>>>>
>>>>>> diff --git a/libdtrace/dt_prov_dtrace.c b/libdtrace/dt_prov_dtrace.c
>>>>>> +static void dtrace_prov_cleanup(dtrace_hdl_t *dtp)
>>>>>> +{
>>>>>> +	char *probes[] = { "BEGIN", "END" };
>>>>>> +	dtrace_probedesc_t pdesc;
>>>>>> +	int i, fd;
>>>>>> +
>>>>>> +	/* start constructing a probe description */
>>>>>> +	pdesc.id = DTRACE_IDNONE;
>>>>>> +	pdesc.prv = "dtrace";
>>>>>> +	pdesc.mod = "";
>>>>>> +	pdesc.fun = "";
>>>>>> +
>>>>>> +	/* clear the BEGIN and END uprobes */
>>>>>> +	fd = open(UPROBE_EVENTS, O_WRONLY | O_APPEND);
>>>>>> +	if (fd == -1)
>>>>>> +		return;
>>>>>> +	for (i = 0; i < sizeof(probes) / sizeof(*probes); i++) {
>>>>>> +		dt_probe_t	*prb;
>>>>>> +
>>>>>> +		/* close the fd if possible */
>>>>>> +		pdesc.prb = probes[i];
>>>>>> +		prb = dt_probe_lookup(dtp, &pdesc);
>>>>>> +		if (prb && prb->event_fd != -1) {
>>>>>> +			close(prb->event_fd);
>>>>>> +			prb->event_fd = -1;
>>>>>> +		}
>>>>>> +
>>>>>> +		/* clear the UPROBE_EVENTS entry */
>>>>>> +		dprintf(fd, "-:dtrace_%d/%s\n", getpid(), probes[i]);
>>>>>> +	}
>>>>>> +	close(fd);
>>>>>> +}

If I understand you correctly, you want dt_provider_destroy() to iterate 
over a provider's probes and call the provider's cleanup function for 
each probe.  To me, that doesn't make sense because:

*)  Currently, we have no provider that wants such code.

*)  If a provider has lots of probes and has something (like 
opening/closing some common tracefs file) that could be amortized over 
all those probes, then the provider would like to handle the probe 
iteration rather than repeating that common work for each probe.  (And I 
could imagine there might be a provider that might have some mechanism 
for cleanup that does not even involve looping over its constituent 
probes.  I have no idea, though.  That's just speculation.)

Anyhow, I have no real interest in debating this.  Attached are sample 
patches.  Let me know which style you like and I can clean it up and 
post it.  The alternatives are:

#1)  What I previously posted.  That is, if a provider has any cleanup 
to do, it supplies a cleanup function that does whatever is necessary.  
E.g., if the provider wants to loop over its probes, its cleanup 
function would do so.

#2)  dt_provider_destroy() iterates over all its probes with a 
dtrace_probe_iter() call, passing a provider-specific per-probe callback 
function to the iterator.  The provider-cleanup code is attached as 
2a.patch and the BEGIN-END-specific code is part of 2b.patch.

#3)  dt_provider_destroy() iterates over all its probes by looping over 
the by-provider hash table.  This is basically what dtrace_probe_iter() 
would end up doing.  The provider-cleanup code is attached as 3a.patch 
and the BEGIN-END-specific code is part of 3b.patch.

#4)  Another option -- no code attached -- is to combine #1, #2, and 
#3.  That is:

     a) Have dt_provider_destroy() call a per-provider cleanup function.

     b) Introduce a new function that is like #2 or #3 in that it 
iterates over
         the probes of a particular provider.

     c) If any provider's cleanup function would like to iterate over the
         the provider's probes, then it could call the new function.

If #4 seems of interest, I guess I could develop a patch for that. Just 
let me know.  I'm guessing here what you're looking for.  Let me know if 
any of the above is headed down the right path.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2a.patch
Type: text/x-patch
Size: 1540 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/dtrace-devel/attachments/20200403/016e1466/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2b.patch
Type: text/x-patch
Size: 7293 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/dtrace-devel/attachments/20200403/016e1466/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3a.patch
Type: text/x-patch
Size: 1921 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/dtrace-devel/attachments/20200403/016e1466/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3b.patch
Type: text/x-patch
Size: 7105 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/dtrace-devel/attachments/20200403/016e1466/attachment-0003.bin 


More information about the DTrace-devel mailing list