[DTrace-devel] [PATCH v3 0/9] stapsdt provider: simple system-wide probing

[Alan Maguire]

On 16/01/2026 15:33, Kris Van Hees wrote:
> On Fri, Jan 16, 2026 at 03:10:52PM +0000, Alan Maguire wrote:
>> On 16/01/2026 14:48, Kris Van Hees wrote:
>>> I think I am missing something...  IS it your intent that this patch provides
>>> for full system-wide tracing with wildcard support, i.e. where you can use a
>>> probe specification with wildcards that is not satisfied yet by any probes in
>>> userspace processes, and as processes are started, dtrace would attach to the
>>> probes and start tracing them?
>>>
>>
>> Yep; this works, along with tracing of existing processes for the traced
>> object. See the documentation patch for an example of doing
>> this with python. The example will trace python probes in python processes
>> that were started either before or after tracing has begun.
>>  
>>> I do not see how this patch series accomplishes that.  If anything, the tests
>>> are all using direct invocation of a single program being traced, so the probes
>>> are guaranteed to be available (discoverable) at the time of D script
>>> compilation.  I do not see any test that ensures that a 2nd process with probes
>>> that matches the probe specification would also be traced correctly.  There is
>>> also no test that demonstrates that starting dtrace with -Z (allowing probe
>>> specifications that cannot be satisfied yet) and then starting a process with
>>> matching stap probes in it results in being able to trace those probes.
>>>
>>
>> That's more an issue with the tests than the functionality itself. I can
>> expand the tests to more fully demonstrate this. It's just easier in
>> practice to invoke the associated command with 'dtrace -c'.
> 
> OK, but without tests that actually exercise the functionality, there is no
> good way to verify that the implementation does the right thing, and that it
> will keep doing that (i.e. detect any regressions).  Without tests that
> exercise the functionality, we cannot review and merge the patch series.
> 
>>> So, I do think I am misunderstanding what this patch series is aiming to
>>> accomplish, which is probably the reason I am having a heard time reviewing it.
>>>
>>> ALl the tests in this series, as far as I can see, do not need wildcards at all
>>> because you can simply write prov$target:... and it will trace the correct
>>> process.
>>>
>>> Can you elaborate on what this is intended to provide?  Or if it is meant to
>>> provide system-wide tracing with wildcard support, can you add tests that do
>>> exercise that functionality and show it works?
>>>
>>
>> The tests demonstrate the case where we start system-wide tracing
>> before starting the program we want to trace. In that case 
>> systemwide tracing adds the value that we don't need to trace
>> a specific process in advance; any process that has the probes
>> will trigger firing.  For example, a user wants that functionality to
>> trace probes in future QEMU processes regardless of pid, so that's 
>> definitely something folks want.
> 
> Actually, that is not true.  Since the tests in the series all use dtrace -c,
> the process is started prior to resolving the probe specifications as part of
> the D script compilation.  So, they do not exercise the case of starting
> tracing prior to starting the program at all.
> 
>> The documentation patch demonstrates the case where we want to trace
>> an already running program/library; in that case I started tracing
>> python3 probes and captured (already running) tuned-related events.
>>
>> Both are valuable I think, and the combination of both is too; i.e.
>> regardless of when a process started (whether prior to starting
>> tracing or afterwards) I want to see events.
> 
> Oh, I certainly agree that this is the functionality we want.  I am just saying
> that the tests in the series do not in any way exercise that functionality, so
> there is no testsuite verification that any of this actually works and that if
> a regression were to occur, that there would be tests that show that.
> 
> So, we definitely need tests in this series that show:
> 
> 1. show it works for executables and libraries with -c (you already have those)
> 2. show it works for executables and libraries with a program that was started
>    before dtrace
> 3. show it works for executables and libraries with a program that was started
>    before dtrace AND for a second program that was started after dtrace
> 4. show it works for executables and libraries with two or more programs that
>    get started after dtrace
> 
> (I think those are all the cases one would expect to work)
>

yep, that sounds right. I'll work to add tests to cover these cases explicitly.
What do you want to do about the absolute path support - will I remove it?