centralize definition

Use size_t as the fall back type

Use PTRADDR_TYPE where available

The is a no-op change before I start trickling in about a large collection of kern_ and user_ functions required to handle integer pointer ABI compat with CHERI.

With this stack of changes it's possible to (cross)build world and kernel with ptraddr_t in a system header.

This is a nice improvement over the mix of adhoc versions.

In D54939#1258282, @jhb wrote:

I suspect the old code just predates reliable TLS support in the toolchain so was using the guts of the implementation for pthread_key.

This makes me wonder why not setrlimit_type(id_t id, int /*idtype_t*/ type, int which, const struct rlimit *rlp), but it's not clear most types really want limits so it feels overall like premature generalization.

rebase

proc not prot in clnt_broadcast_resultproc_t

In D54941#1256407, @ngie wrote:

@brooks : not sure if my tree is out of date, but I found a few more references of potential concern:

% rg -l '\(resultproc_t\)' worktree/main/ | sort | sed -e 's,worktree/main/,,g'
...
usr.bin/rup/rup.c
usr.bin/rusers/rusers.c
usr.sbin/bootparamd/callbootd/callbootd.c
usr.sbin/ypbind/ypbind.c

Do those need to be changed?

In D54940#1256279, @glebius wrote:

Question on naming. I would read "resultproc" as "result process". What does "resultprot" stands for?

Alternatively one could avoid passing free to thr_keycreate, but the complexity of the thr_keycreate approach doesn't seem worth it to save sizeof(void *) of TLS storage.

NFC = "No functional change" in this context.

LGTM

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!