I like the idea of the split, but I'm not convinced queue.3 should go away entirely. If nothing else this commit fails to remove all references to queue(3) in the tree and I suspect it's in some people's finger memory. I'd suggest transforming queue.3 into an intro-like manpage with a brief comparison of each of the relevant list/queue types.

In D54663#1250782, @kib wrote:

In D54663#1250781, @brooks wrote:

In D54663#1250766, @kib wrote:

After we agree on the approach and this change lands, I plan to do the pass over uses of val1/val2 in compat32, where int64_t val is used by the host ABI, converting them to freebsd32_uint64_t.

Please consider limiting this sweep to cases where the value will be mis-aligned relative to the struct.

Can you elaborate please, why? I understand that it formally changes nothing.

In D54663#1250766, @kib wrote:

After we agree on the approach and this change lands, I plan to do the pass over uses of val1/val2 in compat32, where int64_t val is used by the host ABI, converting them to freebsd32_uint64_t.

In D54704#1249776, @christos wrote:

Neither lib/virtual_oss nor usr.sbin/virtual_oss build with this patch:

root@freebsd:/mnt/src/lib/virtual_oss # make
Building /usr/obj/mnt/src/amd64.amd64/lib/virtual_oss/null/null.pico
In file included from /mnt/src/lib/virtual_oss/null/null.c:39:
/mnt/src/usr.sbin/virtual_oss/virtual_oss/int.h:33:10: fatal error: 'samplerate.h' file not found
   33 | #include <samplerate.h>

In practice, this would be fine with default CHERI C, but broken with subobject bounds.

In D54702#1249777, @christos wrote:

@ivy Makefile.inc defines:

PACKAGE?=	sound

Is it a problem if the inclusion is removed from here?

I'm not sure if this is the right sorting, but otherwise it's good.

The whole stack of review builds including subdirectories that aren't connected to the build (other then sndio since I didn't have libsndio installed). However, these changes are untested and I've only verified this last change by building and examining the library with nm to verity that they don't include surprising undefined symbols.

In D54605#1248134, @erj wrote:

In D54605#1247812, @brooks wrote:

If this really matters we should find a more maintainable solution.

I'm assuming it probably doesn't matter, at least until someone profiles it. Thanks for looking at it!