So I was aware of this and preferred the pull request. It documented the current policy that's been in place for a while.
I appreciate the views expressed here, but I think it is better to try to resolve this by getting a broader consensus than we can get in a phab review.
I kinda think the project went a little far in subscribing to bde's views on this, but I don't think we'd be well served making a big change to this policy (which has a lot of lurking emotion behind it) via only a phab request.
I do think there's some sympathy for documenting / standardizing at least some of these values, but also a recognition that some are overlapping and confusing and were just Eric's first guess at what to do in sendmail for different errors.

Since these aren't exported or used anywhere, I think they are safe to remove.

What do you do if neither INET nor INET6 are defined? In a lot of cases, it looks like you fail. Likewise for when you don't have the right address family compiled in.

makes sense @emaste. Thanks!

Why though?

The build is good, modulo one quibble.
The rest looks OK, but is really too large for me to review.

ah, mechanically generated code.

Seems reasonable, but it's a bit large to know for sure.

This looks straight forward enough that I'm happy ...

The build stuff looks good.
I can't speak to the hardware.
The extraneous (white space) changes are relatively low for vendor updates and don't get too much .

boot1.efi isn't worth optimizing, especially if we have to add all the attribute((weak))
For me, it only goes from 157184 down to 132608 (with the changes I described here). I forgot to check without the adjustments with these changes unvarnished... It's still 15% savings...
And for boot1.efi, we don't want the full libsa... there's several subparts to libsa that kinda live together in this library: low level, libc stuff, filesystem support. We don't want all of that in boot1.efi, so adding whole-archive is counter productive and unnecessary. We don't use the filesystem support at all in boot1.efi.

In D44872#1023224, @sobomax wrote:

@imp I think at one point you would be pulling just the devpath.c from the libsa, but then you gave up and started to pull the whole circus. But it continued to pull that one still. Fixed in the new rev.

If it doesn't work, it's been broken long enough for us to retire.
IIRC, though, Oskar was working on making at least some TI SoCs working.
FreeBSD 11 or maybe early 12 was the last time my Pandaboard booted.

I may have been responsible for some of this damage

ah, can't just close it :(

This is my detritis... 314542de6d0a0 actually resolved this.

hmmm, maybe I should find and commit this.

This looks good.

In D45042#1027404, @andrew wrote:

I've been thinking about adding PAGE_SIZE_MAX/PAGE_SHIFT_MAX or similar to arm64 to define the largest page size the kernel could support. We could then use that here if it's defined.

Thanks for the rework!
I'm just finishing a nvme-cli port :)

In D40676#1027003, @theraven wrote:

After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled

Are systems without Capsicum still supported? I thought that option was removed in 14.

I've run this patch from you and noticed no world build time regressions with a 4k kernel