Re: [PATCH v3 0/9] stapsdt provider: simple system-wide probing
Kris Van Hees <[email protected]> Fri, 16 Jan 2026 11:22:13 -0500
| Newsgroups | dev.linux.lists.dtrace |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Jan 16, 2026 at 03:36:01PM +0000, Alan Maguire wrote: << trimmed >> > > 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. Thanks. > What do you want to do about the absolute path support - will I remove it? Let's leave it in for now - once we have the tests, I can review this more in detail, and we can evaluate better what the best approach may be. If adding support for absolute paths in the module component, then we will have to rework more in the lexer to support that without side-effects. If using library path turns out to be the best way to go after all, we can revive that. But I won't know until we have full tests and I can do a better review and make more informed suggestions.