From: Nick Alcock <nick.alcock@oracle.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] rawfbt: new provider
Date: Mon, 09 Dec 2024 16:29:19 +0000 [thread overview]
Message-ID: <878qson7kw.fsf@esperi.org.uk> (raw)
In-Reply-To: <827f0154-48c9-4092-a8f9-5f5116049899@oracle.com> (Alan Maguire's message of "Mon, 9 Dec 2024 10:37:37 +0000")
On 9 Dec 2024, Alan Maguire stated:
> On 06/12/2024 16:33, Kris Van Hees wrote:
>> On Fri, Dec 06, 2024 at 10:35:50AM +0000, Alan Maguire wrote:
>>> On 05/12/2024 19:42, Kris Van Hees wrote:
>>>> This provider provides access to all kprobe-based probes that are
>>>> available on the system. This includes any compiler-generated
>>>> optimized variants of functions, named <func>.<suffix>.
>>>>
>>>
>>> This is great! Having a rawfbt allows users to still trace cases
>>> where fprobe can't currently handle.
>>>
>>> On the .suffix; I get that this is intended to be a raw provider, but
>>> would it be better for stability to expose these functions as "func"
>>> rather than "func.suffix"? It becomes difficult to write portable
>>> scripts when suffixes are included, because wildcarding
>>>
>>> rawfbt::func*:entry
>>>
>>> ...to catch both suffixed and non-suffixed variants may end up tracing
>>> func, func.suffix but also func2 etc.
>>
>> The trouble is that exposing <func>.<suffix> as <func> will mean that you
>> automatically end up trying to probe *any* <func>.<suffix> whenever you
>> place a probe on <func> using rawfbt, which is not necessarily what you may
>> want. And there would not be any way to avoid that.
>>
>> But by not collapsing them, you have the ability to catch them all anyway,
>> if you want, by specifying <func>, <func>.* instead of <func>.
>
> I tried that with the rawfbt code but got:
>
> # dtrace -n 'rawfbt::xfs_cleanup_inode.*:entry {}'
> dtrace: description 'rawfbt::xfs_cleanup_inode.*:entry ' matched 1 probe
> ^C
>
> This matches xfs_cleanup_inode.isra.0, looks good so far. However:
>
> # dtrace -n
> 'rawfbt::xfs_cleanup_inode:entry,rawfbt::xfs_cleanup_inode.*:entry {}'
> dtrace: invalid probe specifier
> rawfbt::xfs_cfs_cleanup_inode:entry,rawfbt::xfs_cleanup_inode.*:entry
> {}: probe description rawfbt::xfs_cfs_cleanup_inode:entry does not match
> any probes
>
> So the absence of the non-suffixed function (which we included for
> portability) triggers the failure. So looks like it will be necessary to
> add -Z:
>
> # /sbin/dtrace -Zn
> 'rawfbt::xfs_cfs_cleanup_inode:entry,rawfbt::xfs_cleanup_inode.*:entry {}'
> dtrace: description
> 'rawfbt::xfs_cfs_cleanup_inode:entry,rawfbt::xfs_cleanup_inode.*:entry '
> matched 1 probe
>
> So I guess as long as we document this clearly for folks wanting to to
> use rawfbt to write portable scripts, it should be okay.
Agreed. Documented behaviour, trivial workaround, maybe can be improved
later -- maybe we shouldn't get a 'no probes' error unless *every probe*
in a probe list is unmatched? There are good reasons for both... maybe
we should add "foo & bar" and "foo | bar" and parens for precedence in
later releases, but this is huge overdesign :P
--
NULL && (void)
next prev parent reply other threads:[~2024-12-09 16:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 19:42 [PATCH] rawfbt: new provider Kris Van Hees
2024-12-05 23:23 ` Eugene Loh
2024-12-06 10:35 ` Alan Maguire
2024-12-06 16:33 ` Kris Van Hees
2024-12-09 10:37 ` Alan Maguire
2024-12-09 16:29 ` Nick Alcock [this message]
2024-12-09 16:57 ` Kris Van Hees
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=878qson7kw.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=alan.maguire@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
--cc=kris.van.hees@oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.