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!

In D54605#1247657, @erj wrote:

In D54605#1247601, @brooks wrote:

For additional context, I took a look at the disassembly on amd64 and the memsets are all expanded in place:

Did you look at the assembly from before the change and did it look like the post-memset change contents? I'm curious about what that custom zeroing code looked like and what it achieved.

In D54553#1247465, @olce wrote:

I fail to see any usefulness of CACHE_LARGE_PAD when it was introduced, which corresponds to aligning CACHE_ZONE_LARGE_SIZE to struct namecache_ts. So I'd just drop the corresponding roundup2(), with the benefit of not requiring a struct namecache_ts alignment for CACHE_ZONE_LARGE_SIZE (but then you have to change the corresponding static assertion).

Fix up comment removing errors

Rename CACHE_ZONE_ALIGNMENT to CACHE_ZONE_ALIGN_MASK and use it
consistenly.

Drop *_zero functions entierly

For additional context, I took a look at the disassembly on amd64 and the memsets are all expanded in place:

;       memset(pi, 0, sizeof(*pi));
    8461: 48 c7 85 78 ff ff ff 00 00 00 00      movq    $0x0, -0x88(%rbp)
    846c: 48 c7 85 70 ff ff ff 00 00 00 00      movq    $0x0, -0x90(%rbp)
    8477: 48 c7 85 68 ff ff ff 00 00 00 00      movq    $0x0, -0x98(%rbp)
    8482: 48 c7 85 60 ff ff ff 00 00 00 00      movq    $0x0, -0xa0(%rbp)
    848d: 48 c7 85 58 ff ff ff 00 00 00 00      movq    $0x0, -0xa8(%rbp)
    8498: 48 c7 85 50 ff ff ff 00 00 00 00      movq    $0x0, -0xb0(%rbp)
...
;       memset(ri, 0, sizeof(*ri));
    8b1d: 48 c7 85 78 ff ff ff 00 00 00 00      movq    $0x0, -0x88(%rbp)
    8b28: 48 c7 85 70 ff ff ff 00 00 00 00      movq    $0x0, -0x90(%rbp)
    8b33: 48 c7 85 60 ff ff ff 00 00 00 00      movq    $0x0, -0xa0(%rbp)
    8b3e: 48 c7 85 58 ff ff ff 00 00 00 00      movq    $0x0, -0xa8(%rbp)
    8b49: 48 8b 85 48 ff ff ff          movq    -0xb8(%rbp), %rax
...
;       memset(pi, 0, sizeof(*pi));
    a9aa: 48 c7 45 a0 00 00 00 00       movq    $0x0, -0x60(%rbp)
    a9b2: 48 c7 45 98 00 00 00 00       movq    $0x0, -0x68(%rbp)
    a9ba: 48 c7 45 90 00 00 00 00       movq    $0x0, -0x70(%rbp)
    a9c2: 48 c7 45 88 00 00 00 00       movq    $0x0, -0x78(%rbp)
    a9ca: 48 c7 45 80 00 00 00 00       movq    $0x0, -0x80(%rbp)
    a9d2: 48 c7 85 78 ff ff ff 00 00 00 00      movq    $0x0, -0x88(%rbp)
    a9dd: 48 c7 85 70 ff ff ff 00 00 00 00      movq    $0x0, -0x90(%rbp)
...
;       memset(ri, 0, sizeof(*ri));
    bc7c: 48 c7 45 b0 00 00 00 00       movq    $0x0, -0x50(%rbp)
    bc84: 48 c7 45 a8 00 00 00 00       movq    $0x0, -0x58(%rbp)
    bc8c: 48 c7 45 a0 00 00 00 00       movq    $0x0, -0x60(%rbp)
    bc94: 48 c7 45 98 00 00 00 00       movq    $0x0, -0x68(%rbp)
    bc9c: 48 c7 45 90 00 00 00 00       movq    $0x0, -0x70(%rbp)
...
;       memset(pi, 0, sizeof(*pi));
    dc56: 48 c7 45 c8 00 00 00 00       movq    $0x0, -0x38(%rbp)
    dc5e: 48 c7 45 c0 00 00 00 00       movq    $0x0, -0x40(%rbp)
    dc66: 48 c7 45 b8 00 00 00 00       movq    $0x0, -0x48(%rbp)
    dc6e: 48 c7 45 b0 00 00 00 00       movq    $0x0, -0x50(%rbp)
    dc76: 48 c7 45 a8 00 00 00 00       movq    $0x0, -0x58(%rbp)
    dc7e: 48 c7 45 a0 00 00 00 00       movq    $0x0, -0x60(%rbp)
    dc86: 48 c7 45 98 00 00 00 00       movq    $0x0, -0x68(%rbp)

CHERI adds yet another branch to the ifdefs and makes this worse and harder to maintain so it's time for it to go. The compiler is also free to recognize the pattern here as memset and replace the code with a libcall so this optimization isn't reliable in any way.

Update the CACHE_PATH_CUTOFF comment adding more context and values.

Restore CACHE_ZONE_ALIGNMENT

Address most of @jhb's feedback. Remvoe CACHE_ZONE_ALIGNMENT entierly
in favor of _Alignof(struct namecache_ts).

This passes a universe build with:

D54301 and D54297 will resolve this issue

LGTM. Out of paranoia, I verified using compiler explorer that it's reliably const enough to use in a macro even at -O0 with an old clang.

I don't care how it's fixed, but I will commit this pretty soon if a broader fix isn't added. The linuxkpi fix should never have been committed without a fallback.

Bump compiler version to 19.1.0 since development versions may not
include __builtin_popcountg.