re: bin/58630: dtrace is "hit or miss", but mostly "miss"

The following reply was made to PR bin/58630; it has been noted by GNATS.

From: RVP <[email protected]>
To: [email protected]
Cc: 
Subject: re: bin/58630: dtrace is "hit or miss", but mostly "miss"
Date: Thu, 9 Jul 2026 07:09:30 +0000 (UTC)

 On Sat, 24 Aug 2024, [email protected] wrote:
 
 > On Sat, 24 Aug 2024, matthew green wrote:
 >
 > > this is a caveat of dtrace that i don't see - i normally
 > > run it as root.  one could enable access to /dev/ksyms
 > > by accepting the info leak (kernel addresses) to all or
 > > perhaps making relevant users part of kmem group.
 > >
 >
 > No need. Comparing with FreeBSD gives a clue:
 >
 > ```
 > diff -urN a/src/external/cddl/osnet/lib/libdtrace/psinfo.d b/src/external/cddl/osnet/lib/libdtrace/psinfo.d
 > --- a/src/external/cddl/osnet/lib/libdtrace/psinfo.d	2018-05-28 21:05:09.000000000 +0000
 > +++ b/src/external/cddl/osnet/lib/libdtrace/psinfo.d	2024-08-24 06:23:00.489064017 +0000
 > @@ -30,6 +30,8 @@
 >    * Use is subject to license terms.
 >    */
 >
 > +#pragma D depends_on module netbsd
 > +
 >   typedef struct psinfo {
 >   	int	pr_nlwp;	/* number of threads */
 >   	pid_t	pr_pid;		/* unique process id */
 > ```
 >
 > Then, that file is skipped if /dev/ksyms can't be read--which isn't fatal
 > for _this_ dtrace use-case.
 >
 
 Bump!
 
 See also the dup PR toolchain/58682.
 
 -RVP