I looked and on x86 we use acpi_identify() for this sort of thing, though a bit later when deciding which nexus driver to attach (on x86, we either use an ACPI "nexus0" device when using ACPI, or we use a legacy "nexus0" device). acpi_identify() honors 'hint.acpi.0.disabled=1' as well as applying sanity checks on the RSDP and RSDT/XSDT. Here, kern.cfg.order seems to duplicate some of that functionality but in a different way.

In the description, do you mean has_acpi is set "before" walking the XDST (rather than "by")? If so, I think Andrew's suggestion of AcpiOsRootPointer() would be good. I think it's a bit more readable than a bare resource_int_fetch, and it more closely matches what OF does for example (calling OF_peer() rather than making use of it's implementation details).

Passes running tests. I'm going to merge this to unbreak the build.

• Tweak the comment a bit further.

• Use refcount_load().
• Note limitations of CRIOGET compat shim.

This will be useful for Morello (CHERI aarch64) support where these will be capabilities instead of uint64_t for a pure-cap kernel.

RISC-V has similar changes in D27357

• Fix a few nits reported by mandoc.

@gbe Hmm, igor was happy, but mandoc found a couple of nits. tcp.4 has many other existing mandoc complaints but I will let those be.

• Reorder to satisfy portlint.

Added a bug for the xcscope.el breakage here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251029

Trimmed ARGSUSED in the followup commit that moves the function.

In D27064#604646, @markj wrote:

Sorry, missed this comment earlier.

In D27064#603981, @jhb wrote:

Arguably we shouldn't really be checking for NULL pointers to control copyout as if you request an operation that needs to write output and submit a NULL pointer you should get EFAULT rather than success but the output data is lost. That is, we should be writing to the output always for operations that generate output (everything but CSP_MODE_DIGEST I think which only writes to the mac pointer).

I agree.

We should perhaps reject request with EINVAL if they pass in non-NULL pointers for fields that should be NULL as well (e.g. dst for a digest operation should be NULL, and the iv should be NULL for operations that don't use an iv).

That seems reasonable to me. The only argument against it is that it might break existing software. We could perhaps introduce new ioctls with stricter behaviour and deprecate the old ones.