Re: port-i386/59402 (Inconsistently-guarded macro definitions in ptrace.h header files)

["David H. Gutteridge via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-i386/59402; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: riastradh%NetBSD.org@localhost
Subject: Re: port-i386/59402 (Inconsistently-guarded macro definitions in
 ptrace.h header files)
Date: Fri, 13 Jun 2025 21:36:14 -0400

 On Tue, 06 May 2025 at 23:44:57 +0000, riastradh%NetBSD.org@localhost wrote:
 > [...] I'd like to better understand how sysutils/lsof has dug
 > itself into this hole.
 >
 > Does it maybe do something really stupid like this?
 >
 > #include <sys/ptrace.h>
 >
 > #define _KERNEL
 > #include <miscfs/procfs/procfs.h>
 > #undef _KERNEL
 >
 > That's apt to cause all kinds of havoc...  I'm also hesitant to ask
 > what lsof hopes to accomplish by defining _KERNEL at all (and not, say,
 > _KMEMUSER or _KERNTYPES) other than shooting itself in the foot.
 
 Yes, by (unfortunate) necessity, per tnn@'s commit patch-af v. 1.21:
 "machine/ptrace.h pulls in sys/module_hook.h after 2019-11-27 under _KERNEL
 This corresponds to NetBSD 9.99.19.
 sys/module_hook.h is not installed.
 Ergo sys/ptrace.h must be included /without/ defining _KERNEL."
 
 Which leads to the question why procfs.h with _KERNEL is required.
 That's because lsof wants to access procfs internals in order to report
 on different node types from its perspective. It's using the kvm(3)
 interface, which in combination with reaching over into kernel headers
 leads to fragility. There are a lot of hacks in some of the NetBSD
 support files it uses, some from upstream and quite old, others added by
 us later. (This extends well beyond procfs, e.g., it uses kvm(3) rather
 than the sysctl(3) interface to get PCB information, which led to more
 kludges.)
 
 I'm aware of several packages that try to deal with issues like this.
 lsof and net-snmp do it one way (many kludges to reach over into stuff
 expected to be kernel-only in installed base header files), while the
 haxm package instead sources headers found under BSDSRCDIR.
 
 Dave
 
 PS concerning kvm(3) rather than sysctl(3) use in general by these kinds
 of packages, I haven't analyzed all the requirements, but I inferred
 this isn't just due to a legacy practice but rather sysctl(3) simply
 doesn't expose everything these packages want, even where they appear
 to overlap in general (e.g., networking-related data).