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?

strchr and strchrnul imported in 7f72497ef756ff7d03d5560c2d1c1f92f73fcb52, already formatted
strcspn was dropped from D17630

(Original review to import these string functions was still open in D17630; we imported other musl string functions in rS315467, rS346054, rS351700)

regen with clang-format17 and D29870 applied

Updated D26340 with this applied and it looks good

Regen with D29870 applied

rerun with clang-format17 and up-to-date .clang-format in the tree

Looks reasonable - I think it was addressing an issue that does not really exist now.

OK

We make use of the empty slots in some cases, e.g. see usb_quirk_get_entry with do_alloc. How will that be handled?

OK, but this is one case where going beyond 80 cols is sensible (and keeping the whole string intact) -- sometimes people will want to grep the source to find an error message and may grep for more than one mode.

do we have user-facing documentation? maybe just expanding WITHOUT_SSP's description?

I was going to do the same thing in namei.h but indeed there's no reason for it to be in the header

Is hw.snd.maxunit documented anywhere today? I suspect we should have an entry in UPDATING at least reporting that it's removed.

• leave #ifndef CAPSICUM in the source requested by @des (for the benefit of downstreams)
• remove src.opts.mk logic

Should we change the in-kernel default as well? It will normally be overridden by the rc.conf setting so it doesn't have a practical impact but probably good for consistency.

@bz I put this in my wipbsd tree on Feb 18, and I have been switching between that tree and main since then. I haven't observed any issue attributable to this change. I still do see one Invalid TXQ sometime in early boot.

I find it a little confusing with the verb & noun use of set in set_software_cipher_set - do you think set_software_ciphers (or set_sw_ciphers) is reasonable?

add man page update

Do we need to add support to e.g. ELF Tool Chain readelf and nm to decode these values?

If it's not too much trouble it would be good to link to the commit that removed the last reference, or maybe just mention "...the ISA sound drivers that...". (I assume it is the ISA drivers I removed that were the consumers of these flags.)

I don't object but we already have :record: or :play: (elsewhere) in the description, is there any case where this won't be the case?

this one can mention that there are no consumers of the build option left in the tree

IMO this is sensible to be in the repo, but in share/ doesn't feel right

Replaced with D44815 and D44814

I think "log a message by printing a packet" is probably not what you mean though