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

[gnats-admin%netbsd.org@localhost]

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

From: RVP <rvp%SDF.ORG@localhost>
To: matthew green <mrg%eterna23.net@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: re: bin/58630: dtrace is "hit or miss", but mostly "miss"
Date: Sat, 24 Aug 2024 06:31:04 +0000 (UTC)

 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.
 
 HTH,
 -RVP