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.
next prev parent 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