Sorry to Statler / Waldorf

I believe this will be ABI-compatible so there should be no trouble upgrading across the commit

In theory I should probablu duplicate kmemdup and use kvmalloc() so in case someone ever decided to re-define kvmalloc/kvfree we wouldn't notice?

I see: AMD Extended Feature Extensions ID EBX=0x79bef25f<CLZERO,IRPerf,XSaveErPtr,INVLPGB,RDPRU,BE,WBNOINVD,IBPB,INT_WBINVD,IBRS,STIBP,STIBP_ALWAYSON,PREFER_IBRS,SAMEMODE_IBRS,NOLMSLE,INVLPGBNEST,PPIN,SSBD,CPPC,PSFD,BTC_NO,IBPB_RET>

Do we have our approach documented somewhere? This looks acceptable given that we already #define kvfree(arg) kfree(arg) but it would be good to have that mentioned somewhere.

Looks good except one copy-pasto I think

You could turn it around maybe - "if your friend complains that the emoji you sent won't display, you can..."

In my local tree:

building src.conf.5 man page from files in /home/emaste/src/freebsd-git/wipbsd/tools/build/options
...........................make[1]: "/home/emaste/src/freebsd-git/wipbsd/share/mk/bsd.mkopt.mk" line 71: warning: WITHOUT_CASPER option ignored: it is no longer supported
make[1]: "/home/emaste/src/freebsd-git/wipbsd/share/mk/bsd.mkopt.mk" line 71: warning: WITHOUT_CASPER option ignored: it is no longer supported
................................................................................................................................................................................................................................
ignoring duplicate option INIT_ALL

OPT_ are not handled per-target

This is a breaking change. 3rd party drivers should take care of it.

Add comment suggested by @jhb

Regarding the race, it maybe be very hard to hit it

This seems sensible; I'd expect mixer 1 to refer to /dev/mixer1 not whatever the second mixer happens to be. I don't think a race condition like you describe is even required, right? Removing the device providing /dev/mixer0 means the system will always be in this state?

This is supposed to be for diagnostic tools only, so it shouldn't really matter much. Assuming we refer to a card by index anywhere (in dmesg, say) it makes sense for numcards to report the highest card number -- OK.

Is there an issue open somewhere for the gcc deficiency?

This ordering (sodisconnect() followed by the soclose tsleep loop) dates to the original import BSD 4.4 Lite Kernel Sources. I agree with @tuexen's comment above, understanding what happens with TCP is very important.

No objection from core@

@jhb will push his version instead

Handled by 23099099196548550461ba427dcf09dcfb01878d / D40779

In D45114#1028908, @dim wrote:

libcbor is contrib'd code, right? Otherwise I'd just put an #ifdef __clang__ around it :)

In D45114#1028902, @jhb wrote:

I used this patch locally since we have a builtin for this warning in bsd.sys.mk:

In D45115#1028873, @imp wrote:

Why though?

Also update comment in source code

I'm sure there are many more entries that should make it into the notes, but these are good

switch userland default as well

I couldn't find a useful reference for a name elsewhere so I think it's fine, although I might go with LENOVO_IDEAPAD3_SUBVENDOR

In D30190#677973, @se wrote:

In D30190#677963, @dim wrote:

Hm, this seems safe, but would indeed have to be checked with upstream too. They tend to want to change almost anything that comes in via reviews, so if you have time to wait, we could discuss it upstream first. Unless you're in a hurry and need this, then it's OK to commit.

I'd rather see this come to our tree via the upstream. I'll just keep this change in my sources until the upstream update arrives ...

I think this is OK - FreeBSD is starting on the path of retiring 32-bit support. ARMv7 support will remain for FreeBSD 15.0, but if a specific SoC isn't working properly today and doesn't have anyone working on it then retiring it now is reasonable.

Do you intend to proceed with this?

Is this patch still relevant?

Ref d8b2693414ae5
It would be great if we had a section 9 manpage for rib_add_default_route