Wrong place for efi_devpath_trim.
No need to walk partitions in efipart_find_parent.
No need for local variable.

With full respect, I have no idea why you want/need these changes to original D13861.
Adding initrd support to top of D13861 is simple (we can use fragments from this patch).
For me most clean way how to solve this situation is:

1. revert original commit.
2. commit D13861 (without putting LINUX_BOOT_ABI to GENERIC)
3. convert this patch to adding initrd support on top of D13861 ( I offering full help for this)
4. fix generation of booti image (by utility program or by some hex editing, having booti header in locore.s is not a right way)

Forget to change description from acpi_thermal.4, which was based.

Fix errors: typo and mandoc -Tlint.

Fix buildworld

Thank you for writing the man page!
I've found a typo. Can you run textproc/igor and "mandoc -Tlint" over the man page and see if they turn up any warnings?

Fix OBJ_ONEMAPPING for shared mapping after shadowing.

For the pkg-plist of x11/nvidia-driver, there should be this:

I ran tests on D22544.64854 for 14 hours. No problems seen.

Bump.

I welcome these changes. The current debug output looks like a mess.
Moreover, part of the files declares (W/D)PRINTF as

per @kevans

Just tidying up.

LGTM. The extra braces you added in order to create scope for the itv variable are stylistically contentious. Some people would disagree with that, because it's not commonly done. But I happen to like that technique myself; no reason for itv to have more scope than necessary.

FWIW I reviewed backing_object users and I think only vm_object_sync() wants these semantics but would also be trivial to convert.

Abandoning this, because it's wrong and we likely need finer-grained (and different) locking at the TTY layer to compensate.

Fix a race between unlocked reference and collapse.

Is it just me or did setting epp break in the latest version?

Looks good to me

Ignoring the one maximum value, is anyone interest in actually reviewing this?

Ah sorry, forgot to reply here. Someone reported an error that seemed like it was caused by this, so I pushed the fix. Turns out he had some sort of environment contamination (building from ports), so it was a bad assumption on my part.

It's ready to go, but I had one more question at https://reviews.freebsd.org/D22492 . I was waiting for your answer, not because it's strictly required but just in case you had something surprising to say.

What is the status of this patch? What help can I be of here? I'll hold off on updating to 2.2.18 (just released) so as not to interfere here.

In D20740#451134, @hselasky wrote:

Patch looks good to me. Did you run with this patch?