sysctl kern.vnode was disabled in commit: https://github.com/freebsd/freebsd-src/commit/acb18acfec97aa7fe26ff48f80a5c3f89c9b542d At the time the concern was with diskless machines and general it may be dangerous in its requirements for locked down memory on large RAM systems. NetBSD and OpenBSD both appear to have kern.vnode from looking at lsof's dialects. So it appears to be safe there in there implementation. Currently the lsof team is waiting on this to be enabled to merge a change to the FreeBSD dialect to use more ABI calls instead of /dev/kmem reads. That leaves the FreeBSD port of lsof unable to read zfs file's locations. There may be other ports that are difficult to maintain because this sysctl is disabled.
In its current form this code does not compile. After fixing all compilation issues, the problem is still that it would try to allocate around hundred of megabytes of kernel memory (contiguous KVA), on any relatively modern machine. Can you explain the high-level interface needed by lsof there? I do not see raw xvnode as anything useful, even for the utility like lsof. If somebody can explain what lsof needs, we perhaps can design proper API that is both useful and implementable.
Currently lsof in ports can't list pathnames for open zfs files. The author of the patch to lsof to use FreeBSD abi (sysctl calls) to replace man of the /dev/kmem reads puts it this way: "The CTL_KERN + KERN_VNODE sysctl needs to work. Without it we cannot access the inode ("NODE" column) nor filter by inode or vnode id, nor determine an open file's filesystem efficiently or sometimes at all (if kinfo_file.kf_path is empty, then statfs() can't work, whereas we can cache results from previous statfs() and match by xvnode.xv_mount). There could be further limitations." If you do lsof with no options it look up all open files belonging to all active processes. It would use this call to obtain that data or it would obtain the same by reading kernel memory. The goals is to reduce or eliminate kernel memory reads by switching to other sources like sysctl calls for the data. If you need more detail about this, here is the thread: https://github.com/lsof-org/lsof/pull/184#issuecomment-1023556335 Also, I may be able to answer more direct questions. But I'm just a motivated user of lsof wishing to regain features lost in recent FreeBSD release after the move to OpenZFS.
Apologies for the typo in the last message "man of the" was apparently auto-corrected from "manual". I also noticed there is a review of the changes needed to make this work: https://reviews.freebsd.org/D34090