why spend a sysconf on it? exposing this with a sysctl seems like a more natural fit, but i'm not going to insist

the current code reads vm.uma.DEVCTL.size, which would be too hacky to rely on if opencoded in callers. hw.bus.devctl_queue and hw.bus.devctl_nomatch_enabled exist. perhaps hw.bus.devctl_msg_size would do the trick?

Now that I'm taking another look, even if going with sysconf, looking at the uma zone is a no-go. One day it might change (e.g., it may get removed altogether) and this will break userspace. A dedicated sysctl with the size is needed, but then I don't see any justificatin for adding a sysconf.

In D61346#1407002, @mjg wrote:

Now that I'm taking another look, even if going with sysconf, looking at the uma zone is a no-go. One day it might change (e.g., it may get removed altogether) and this will break userspace. A dedicated sysctl with the size is needed, but then I don't see any justificatin for adding a sysconf.

The sysconf moves the knowledge of the more likely to break ABI thing into libc, which is friendlier to consumers.

In D61346#1407002, @mjg wrote:

Now that I'm taking another look, even if going with sysconf, looking at the uma zone is a no-go. One day it might change (e.g., it may get removed altogether) and this will break userspace. A dedicated sysctl with the size is needed, but then I don't see any justificatin for adding a sysconf.

When UMA zone moves or changes, the sysconf(2) API stays. That's the point.

In D61346#1407364, @glebius wrote:

In D61346#1407002, @mjg wrote:

Now that I'm taking another look, even if going with sysconf, looking at the uma zone is a no-go. One day it might change (e.g., it may get removed altogether) and this will break userspace. A dedicated sysctl with the size is needed, but then I don't see any justificatin for adding a sysconf.

When UMA zone moves or changes, the sysconf(2) API stays. That's the point.

UMA zone change breaks libc, so it needs patching. If for example there is a deployment with now-stale release in a chroot using this sysconf, it is suddenly going to break as it wont get the libc update.

The mere existence of the UMA zone, even ignoring names and sizes, is an implementation detail which does not have to be relied on in any capacity.

If you add sysctl hw.bus.devctl_maxrecord you will provide a trivial future-proof way of getting the info.

Say FreeBSD 15.2 ships with this sysconf and FreeBSD 16.0 removes the zone. Then COMPAT_FREEBSD15 will require sysctl vm.uma.DEVCTL.size to be present anyway. No such problem with my proposal as it decouples the information from an implementation detail at kernel level.