public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Eugene Loh <eugene.loh@oracle.com>
To: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH v3 11/19] Support USDT wildcard provider descriptions
Date: Fri, 25 Oct 2024 01:56:34 -0400	[thread overview]
Message-ID: <2367490a-554f-6bd0-c7cb-9ff3b5480c0d@oracle.com> (raw)
In-Reply-To: <Zxp4AmW2HB8G0CBd@kvh-deb-bpf.us.oracle.com>

On 10/24/24 12:38, Kris Van Hees wrote:

> On Tue, Sep 24, 2024 at 04:25:52PM -0400, eugene.loh@oracle.com wrote:
>> From: Eugene Loh <eugene.loh@oracle.com>
>>
>> To look for pid probes, whose pid values must be specified explicitly,
>> we can require that the provider description should end in a digit.
>>
>> For USDT probes, however, there can be wildcard descriptions.  This
>> includes a blank provider description as well as a description that
>> ends in an '*'.
> What about 'test*1234' or 'test*12*' or 'test*1*2*4'?  All should match
> 'test_prov1234', right?

Right.  "test*1234" and "test*1*2*4" already end in a digit, so were 
already included.
"test*12*" ends in an '*' and so is added by the patch.

>> So, in dt_setcontext(), expand the criteria appropriately.  And
>> modify dt_pid_create_probes() accordingly.
>>
>> This is rudimentary support.  We still need to:
>> - handle globs in dt_pid_create_probes_module()
>> - add process monitoring / inotify
>>
>> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
>>
>> diff --git a/libdtrace/dt_cc.c b/libdtrace/dt_cc.c
>> index 12104fc21..62482a70f 100644
>> --- a/libdtrace/dt_cc.c
>> +++ b/libdtrace/dt_cc.c
>> @@ -273,8 +273,9 @@ dt_setcontext(dtrace_hdl_t *dtp, const dtrace_probedesc_t *pdp)
>>   	 * On an error, dt_pid_create_probes() will set the error message
>>   	 * and tag -- we just have to longjmp() out of here.
>>   	 */
>> -	if (pdp->prv && pdp->prv[0] &&
>> -	    isdigit(pdp->prv[strlen(pdp->prv) - 1]) &&
>> +	if (pdp->prv &&
>> +	    (pdp->prv[0] == '\0' || isdigit(pdp->prv[strlen(pdp->prv) - 1]) ||
>> +	             pdp->prv[strlen(pdp->prv) - 1] == '*') &&
>>   	    ((pvp = dt_provider_lookup(dtp, pdp->prv)) == NULL ||
>>   	     pvp->pv_flags & DT_PROVIDER_PID) &&
>>   	    dt_pid_create_probes((dtrace_probedesc_t *)pdp, dtp, yypcb) != 0) {
> First of all, I am not sure that combining pid and USDT probe handling here
> by means of dt_pid_create_probes() makes sense under the new scheme.  In fact,
> dt_pid_create_probes() may no longer be needed because handling them separately
> seems better.
>
> Then there are two cases:
>
>   - For pid probes, a provider name must have been supplied and it must have a
>     digit as last character.  So, for pid probes you can keep the original code
>     aside from replacing dt_pid_create_probes() with dt_pid_create_pid_probes().
>
>   - For USDT probes, there aren't any restrictions, other than the ones already
>     done in dt_pid_create_usdt_probes().  So, a call to that function should be
>     done here without any conditional.

Okay, though I don't really understand the dt_setcontext() logic. E.g., 
we test pdp->prv!=NULL.  If it could be NULL, then we should still check 
before calling dt_pid_create_usdt_probes(). Stuff like that.  But I made 
your suggested change and it passed tests...  so good enough for me.

  reply	other threads:[~2024-10-25  5:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-24 20:25 [PATCH v7 03/19] Deprecate enabled probe ID (epid) eugene.loh
2024-09-24 20:25 ` [PATCH v2 05/19] Split dt_pid_create_probes() into pid and USDT functions eugene.loh
2024-09-24 20:25 ` [PATCH v3 07/19] Create the BPF usdt_prids map eugene.loh
2024-09-24 20:25 ` [PATCH v3 09/19] Use usdt_prids map to call clauses conditionally for USDT probes eugene.loh
2024-09-24 20:25 ` [PATCH v3 11/19] Support USDT wildcard provider descriptions eugene.loh
2024-10-24 16:38   ` Kris Van Hees
2024-10-25  5:56     ` Eugene Loh [this message]
2024-10-25 12:48       ` Kris Van Hees
2024-09-24 20:25 ` [PATCH v2 14/19] Ignore clauses in USDT trampoline if we know they are impossible eugene.loh
2024-09-24 20:25 ` [PATCH v2 15/19] Ignore clauses: some clauses are impossible regardless of uprp eugene.loh
2024-10-23 20:28   ` Kris Van Hees
2024-10-24 19:30     ` Eugene Loh
2024-10-24 21:12       ` [DTrace-devel] " Kris Van Hees
2024-10-24 21:53         ` Eugene Loh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2367490a-554f-6bd0-c7cb-9ff3b5480c0d@oracle.com \
    --to=eugene.loh@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox