[DTrace-devel] [PATCH v2 03/04] rawtp: report lockmem issues when determining rawtp argument count

[Kris Van Hees]

On Thu, Nov 30, 2023 at 07:23:03PM -0500, Eugene Loh via DTrace-devel wrote:
> On 11/30/23 10:59, Kris Van Hees via DTrace-devel wrote:
> 
> > No test is added for this condition because any such test would have to
> > be removed again in the next patch, where a better way to retrieve rawtp
> > argument info will be introduced.  This code will remain as a fallback,
> > but we do not have any way to programmatically force it to be used.
> 
> I see this patch is reviewed, but I wanted to weigh in on the test issue.
> 
> Will this code be a fallback on every platform?  How about on OL7? Would OL7
> be missing HAVE_LIBCTF and therefore would be falling back?  With the entire
> patch series in place and running on OL7, I try:
> 
> # dtrace -lvP rawtp -xlockmem=1
> # dtrace -lvP rawtp -xlockmem=unlimited
> # dtrace -lv        -xlockmem=1
> # dtrace -lv        -xlockmem=unlimited
> 
> With "-P rawtp", the highest code path is different from the "default"
> case.  I see that the -xlockmem=1 runs have truncated output relative to
> their "unlimited" companions.  They also have "lockmem" messages.
> 
> I think such a test should be present.  It can be introduced in this patch; 
> the next patch can add a .x file for OL8 and OL9.  Or this patch can say
> that the test will appear in the next patch.  But a test should appear
> somewhere.

Yes, you are right that with the latest version, a test is actuallly possible
on OS versions that provide libdtrace-ctf and NOT libctf.  I will add a test
to exercise this on that particular environment.  However, that will not serve
as a general test for this fallback functionality in the long run because the
libdtrace-ctf library has been deprecated.

So, even though there will be a test, it will be of very limited use.  And in
any even remotely recent environment, it won't be used.