ah, drop callout xr

Added kib based on his observations on my original commit.

add in kib's observations.

Update, per jhb@ review, adopting his wording...

Also, could you you use arc to upload this, or do a diff -U999999 so we can see more of the context?

update based on phk's feedback

Couple of nits.

The nexus parts look good. Don't know if the determination of max address is right....

In D30805#692800, @jhb wrote:

Wait, how did this compile exactly? Does it stop at the first invalid character so that '\008' becomes '\0' and '8'?

Change looks good to me:

basically rewrite hz(9): it now doesn't have anything but the most trivial bits
from NetBSD, so drop the NetBSD copyright on hz.9 as not relevant.

Rewrite again to address review suggestions and concerns.

In D30802#692635, @mav wrote:

Now all three routines hardclock(), statclock() and profclock() are called from the same source of handleevents() in kern_clocksource.c according to eventtimers(4), driven by whatever hardware available on specific system (periodic or one-shot, global or per-cpu, etc), but in any case trying to emulate legacy hz, stathz and profhz rates as much as possible by reprogramming the hardware via eventtimers(9) KPI.

Update to more closely match FreeBSD's implementation, as noted by
mav@. Hopefully this gets closer, but if not...

Try to address ceri's concern

This is similar to the hacks we've done elsewhere in the system. Does it need to be also limited by MAXPHYS?

more / better / vm

accidentally created 2. junking this one.

take up allanjude's suggestion, with a tweak or two (sorry allan,
I did this before I saw your review :)

Add some additional, relevant advice.

more advice

That is, I'd rather see ZFS64

include GENERIC64
options ZFS

etc

I'd really rather we didn't do this... I don't think it's a good idea....

Tweaked a little.
A bit torn on whether to move the bulk of the wording changes up or not...

Wording tweak from bcr
Use .Li markup as used elsewhere for $FreeBSD$
Add ", if applicable" to an earlier mention of $FreeBSD$

s/can/should/

While FreeBSD can run on 486 and 586 class cores, Linux has long ago made the choice to compile for 686 and newer cores only in its popular distributions. FreeBSD changed its default to i686 for 13 as well.
One in theory could run a 486 or 586 binary on a machine of that class. However, that's such a odd-ball combination I'm virtually certain has seen no testing that this is fine.

From a manpage / markup perspective it looks good.
Also, this matches the current function signature.

Given the additional testing reported, I think this is good...

I believe this is probably right. The comment deleted was one I added as I was auditing things...
I didn't have good test case to check.

books/handbook/mirrors/_index.adoc:# make update SVN_UPDATE=yes

Does this need companion commits to the FreeBSD handbook or related docs?