"Whoops", GC phys_start/phys_end now

Simplify, just divide; bd_sectorsize should always be a multiple of 512.

Missed one error condition where we'd kmem_free()

Seems fine to me, thanks!

Address review commente

In D36187#822594, @cperciva wrote:

@kevans On IRC it sounded like you were ok with this -- was that "ok with the concept" or "ok with the code"?

LGTM

In D27318#819456, @gbe wrote:

Is there anything specific that would block a commit?

That seems intuitive enough, thanks! :-)

Change course, expand tzdata to "IANA Time Zone Database (tzdata)" on first use,
then just call it "tzdata" in later references without trying to call it a
distribution or package.

I like it... I'm not really a fan of the naming, but I can't exactly come up with a better suggestion so take that for the very little that it's worth.

Yup, LGTM. Thanks!

The header shims are a bit ugly, but given the context I agree that this is a reasonable stopgap...

exp-run looks good, assuming this is tested to solve the problem run into at Netgate, I think I'm happy with it

I think this looks good to me, modulo a need to bump shlib versions for both libs (iirc; at least libnv) -- I've requested an exp-run with versions bumped (and appropriate entries added to ObsoleteFiles.inc): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264838

Address review feedback (sorry for the delay)

Sorry, I'll take care of this soon.

In D35341#801287, @decke wrote:

In D35341#801255, @kevans wrote:

I really don't think wg uses volatile enough underlying KPIs to decide this is warranted just yet

In theory probably not but in practice 13.0 -> 13.1 caused panics because of that. I have at least
PR264114, PR264111 and two private reports.

I really don't think wg uses volatile enough underlying KPIs to decide this is warranted just yet

Fix files containing ", `, and $. Add tests to cover those names, as well, for
all of these cases.

heh, whoops. sure enough, that's pretty silly.

Highlights:

• Fix devd scripts
• Fix other examples found in the tree
• Fix rrel inheriting lrel prematurely
• Don't allow garbage after %, either

In D34805#788854, @kevans wrote:

In D34805#788848, @kib wrote:

I do not object, but arguably this is the first time ever I see a compat for config. All other features removal resulted in hard error for unmodified configs.

Also 'profile' with mcounters was not working for SMP ever, I believe. So why?

Good point; looking back, I apparently missed that it was NOTES in stable/13 that they hit problems with. Maybe we should just MFC (edit: that part of) aa3ea612be365 and continue punting on this until someone comes up with a broken runnable config.

I do like the idea; just a couple of small nits. It might also be good to note explicitly in the manpage while it may be the case now, verbose information after the first column won't necessarily be formatted in a tabular manner in case we end up finding some reason to expand it.