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

With D37076 committed should this be abandoned?

Is this change still useful?

What should we do with this?

Was committed (tag was Differential not Differential Revision so it did not auto-close).

@0mp if you put just the short version of the review (D38344) Phab will show if its closed or still open. With that change committed there is presumably no reason for this change any longer?

And I guess it's really marking memory beyond this (rounded up end of .text) as non-executable

I assume that's supposed to be "l2 blocks" in the comment message?

Based on discussion on a recent secteam call. After putting this together I discovered D23329, which provides an rc.conf setting defaulting to AUTO which is set to yes (drop) if a routing daemon is enabled, and no if not - so if we do want to make this change we'll want to update rc.d/routing as well.

I wonder if it makes sense to add a section on stack overflow detection to security(7) would make sense

IMO we should either remove them or restore default formats.

I don't think there's a lot of value in keeping the aliases, if we don't also keep the behaviour -- i.e., if some application does expect to open /dev/dspW and send 16-bit samples without doing any other configuration it's not going to work as expected.

how does e.g. /dev/dspW map to 16-bit now?

Looks reasonable to me

Can we decouple userland use in ifconfig? i.e., have ifconfig support 384 bits now

I think this is fine; any further comments @bz?