This should go to https://github.com/openzfs/zfs

This is fine with me, but you could instead strip a leading / from TESTBASE if present, e.g. /usr/lib/debug/${TESTBASE:S,^/,,}. This will be robust against a possible TESTBASE without a leading slash.

Please generate patches with git diff -U99999 or git show -U99999 so that Phab will show context

Actually I think all of these cases no longer exist and we can just remove this functionality altogether.

I think many of these tweaks are slightly more readable or simpler to understand, but that may just be a matter of taste.

Some minor notes

oh it's when I do commit update to add the differential revision to the git commit message

Seems OK -- I imagine it was split out as it is rather long but it does not seem necessary to do so.

add url

whole patch

Does this need an entry in RELNOTES as a followup commit perhaps?

It might be worth giving a heads-up anyway, just so people have a hint if something stops working.

PR: 207898

Minor comment on commit message - imperative, present tense is preferred, so e.g. nvmecontrol: Fix usage typo (or typo in option description etc.)

Thinking a bit more I'd go with what you have here, and we should revisit this just before 15.0 (which shouldn't have any 32-bit except for armv7 anyway).

I've wondered if we should use the order you have here, or go based on tier order (amd64, aarch64, i386, armv7, ...). Or maybe we don't need to think too much, and once i386 is retired the problem solves itself.

IMO it's most important to get the notes into shape for 14.2, and archetypes must receive the same change. (Ideally we would have updated archetypes just before creating the 14.2 notes.) I wouldn't bother changing the old release notes for these. Removing references to drivers that were excised from the tree long ago makes sense, but not for reordering the sections etc.

The Linux folks use coccinelle

Yeah it would be great to have coccinelle for downstream projects to apply the same change in derived repos.

I'm going to commit this as an interim improvement. We can revisit ng_get_composite_len's return type and error handling later on.

This is the sysctl node under which rules are created; they are opaque binary objects and aren't shown by sysctl(8). You can add a rule in ugidfw and then run ktrace -i ugidfw list to see them being used -- something like:

The C code in Lemire's paper uses a uint64_t bound and __uint128_t variable. Maybe it is worth a small note to this effect in the commit message (of course, 32/64 or 64/128 doesn't matter for the algorithm itself).

Restore POSIX_VISIBLE tests - issue was local cross-threading

Oh, on ref15-amd64.freebsd.org I get:

#include <sys/cdefs.h>
#include <stdio.h>

I'm not sure how the build is intended to set __POSIX_VISIBLE for building libc's getentropy.c.

missing word, update test

I don't believe we should change it nor stop documenting it.

Yeah I'd hold off on this until after 14.2 is out the door

Can we simplify this eventually and standardize on only the first case?

typo, mention that it nearly conforms to posix 24

I think we can reduce some duplication in memstick_mkimg later, but this is a great start

let's give some pkgbase people a chance to comment in case this is something which should be fixed on their side