When the kernel is compiled with INVARIANTS, export that as debug.invariants.

[imp]

Test Plan

compile both ways, boot the kernel, make sure it's not backwards :)

[allanjude]

I think it makes more sense to have the sysctl unconditionally. Then its absence just means 'kernel too old to tell'

[imp]

always define debug.invariants.

Updating D3488: When the kernel is compiled with INVARIANTS, export that as

debug.invariants.

[kib]

What is the supposed use of the information in userspace ? Also, if there is a use, the FEATURE() may be more appropriate, with the feature_present(3) libc helper already wrapping the sysctl(2) into more conventient interface.

[imp]

In D3488#71441, @kib wrote:

What is the supposed use of the information in userspace ? Also, if there is a use, the FEATURE() may be more appropriate, with the feature_present(3) libc helper already wrapping the sysctl(2) into more conventient interface.

Here's what I sent to arch@ and this should answer this question:

Many of the performance eating features are exported via some kind of sysctl, usually
patterned after the case of witness as debug.foo. INVARIANTS isn’t one of those
features.

https://reviews.freebsd.org/D3488

implements debug.invariants. Please comment.

I’d thought about adding it to the kern.features sysctl, but thought better of it since it
isn’t a facility that people can use.

If you include the kernel config in the kernel, you can get this information via
config -x | grep INVARIANTS
but not all kernels do that. This is more robust.

I also know that you can load some modules compiled INVARIANTS when the base
kernel isn’t built that way and this won’t reflect that. There’s no good want to include
that information and is an uncommon use case.

Our use case? We have a raft of test machines. Most run without INVARIANTS since
we want to characterize the performance of the release under test. Some are running
INVARIANTS since we want to test the robustness as well, even at the expense of
some performance. To ensure we don’t accidentally include INVARIANTS systems
in the performance number, we’ve adding a key to an internal database that’s driven
off this sysctl.

Comments?

[kib]

I do not quite understand the characterization of kernel.features.* as something that people cannot use, but I do not insist on its use in any way.

[jhb]

I agree with kib that this probably should just be a FEATURE(). That is intended for human consumption just as much as programmatic consumption. The witness case is different because 1) it predates FEATURE(), and 2) there are multiple witness knobs, not just a feature-presence test.

[cem]

This was committed as r287183 and updated to use FEATURE in r287264. Phabricator failed to close the revision automatically because the "Differential Revision:" annotation wasn't the last one in either commit message.