I think this change looks OK as long as wait6(2) is limited to checking children [and perhaps their children, etc]. It doesn’t look to me like it can ever originate the list of processes from allproc or similar, so I believe this is OK?

• Fix grammar nit spotted by @jrtc27.

• Style fix: Differentiate arbitrary integer values from booleans.

Type consistency.

Whitespace fix.

Use a sysctl handler to limit possible values of kern.ipc.pipe_mindirect.

In D29819#669007, @jrtc27 wrote:

pipe.h has:

/*
 * PIPE_MINDIRECT MUST be smaller than PIPE_SIZE and MUST be bigger
 * than PIPE_BUF.
 */

Do we need to do any validation of the value?

Sundry tweaks from @jrtc27.

In D27971#632295, @lwhsu wrote:

In D27971#632293, @arichardson wrote:

Workaround: arc set-config --local history.immutable false. However that won't work if you have a git worktree :( To work around that you need to patch arcanist since upstream doesn't want any contributions (https://secure.phabricator.com/D21438)

I haven't had time to check this, but if we really need to patch arc, we can patch it locally in ports.

In D29369#657694, @andrew wrote:

I wonder if we should be checking for __NO_STRICT_ALIGNMENT (and defining it for architectures other than x86)

• Rename local variable as it holds the systen clock count rather than the cycle counter.

In D28723#643442, @rwatson wrote:

In D28723#643438, @andrew wrote:

Is dtrace_gethrtime run while pinned to a single CPU? My readding of the spec is that it should be identical over all cores as it's based on the system counter, although it this is not the case it could lead to interesting results.

Certainly in the DTrace probe context, the thread is pinned and has interrupts disabled. However, I will check and see if it’s possibly called from non-probe contexts. However, my reading was that this counter should be OK to use in this way. I also confirmed on the RPi4 that the rate is invariant despite CPU clock frequency changes, across multi core.

In D28723#643438, @andrew wrote:

Is dtrace_gethrtime run while pinned to a single CPU? My readding of the spec is that it should be identical over all cores as it's based on the system counter, although it this is not the case it could lead to interesting results.

In D28723#643381, @jrtc27 wrote:

In D28723#643374, @imp wrote:

Seems legit, so long as freq is returned in GHz

freq is Hz, the 1000000000UL is to turn the s into ns.

LGTM. Thanks!

I’d like to think about committing this, if folk wouldn’t mind updating their reviews, with the following commit message:

Update to reflect correct calendar year (courtesy @jrtc27).

I've made a number of updates to the patch as a result of comments and suggestions. It would be especially useful if @jeff could review the code and descriptions to make sure I've correctly interpreted his comments and also not written buggy code.

Actually use CPU 0 as suggested in the comments, not CPU 1.

Comments from @kevans now (believed) addressed relating to cpuset(9) macros.

Based on comments from @kevans, explicitly Xref cpuset(2), and correct
mention of CPU_CLR(9) to CPU_ZERO(9).

Some updates on the patch correcting problems found by @0mp and @jrtc27. Thanks!

Improve whitespace conformance to style(9), courtesy @jrtc27.

Following feedback from jeff, break the example into two:

Following R10:6eebda3bbad9, update this patch to use std.nodebug, which is
much preferred.

In D28091#627733, @jrtc27 wrote:

Hm, my instinct would be to make it include GENERIC-MMCCAM instead and then turn of debugging, especially given the name.

Trim exclusion of memcpy() and bcopy() as @andrew's in-progress patch to
avoid improper FBT instrumentation of functions without conventional stack
frames now solves that problem in a better way.

Update comment for new kernel name.

Candidate commit message (will update Reviewed by notes as needed):

Updates to candidate commit message.

A modified version of this merged in recent changes by @andrew.

• Since non-aarch64 haven't required a memcpy() exclusion in the past, don't exclude it now.

Various fixes to the DTrace FBT provider on FreeBSD/arm64:

In D27878#626721, @imp wrote:

I believe these are good places to add the accounting. They do assume that ANY read or ANY write, even one that also have an error, counts as a message rcv or snd, but I think that's OK.

Shift points where we count messages received or sent to the end of
pipe_read() and pipe_write() so that they count only messages that were
definitely processed. This is somewhat stronger semantics than are
provided for sockets, but since it costs neglibly more to do this, and
the results are potentially more useful, go with that.

An FYI rather than a review: I'm using these patches successfully on my RPi4, and it's proving invaluable. I'm eager to see these committed back to the main tree as soon as everyone feels ready.

Move to freebsd/main from old freebsd/master.