Personally I would put "move umount /dev into a new function" and "add comments" into different commits, but since you've already done it this way there's no point splitting them apart.

I previewed it with

man -l 
```and

Text looks reasonable to me. I did not verify formatting / doc best practices (section order, etc).

LGTM

In D47678#1280070, @emaste wrote:

@bnovkov do you know why the "needs close" check determines this one has already landed? (i.e. fbsd_author_needs_close.html)

In D53472#1281146, @bms wrote:

Any hints about how to expedite a loader build with this in the tree? It would require building a USB image?

In D53472#1281160, @imp wrote:

In D53472#1281146, @bms wrote:

I can point the EFI MonotonicCounter GSoC volunteer here for hints, I did not see how to pass things from loader to kernel in a more structured way being one of the older BIOS generation folk.

file_addmetadata(kfp, MODINFOMD_FW_HANDLE, sizeof(ST), &ST);

Is how it's done. You define a new MODINFOMD_xxxx and you pass it from the loader... The kernel reads with

LGTM

In D53472#1281146, @bms wrote:

I can point the EFI MonotonicCounter GSoC volunteer here for hints, I did not see how to pass things from loader to kernel in a more structured way being one of the older BIOS generation folk.

In D55641#1276922, @ali_mashtizadeh.com wrote:

Looks good to me, just be aware that I landed a fix that forces us to whitelist json fields. I don't see any new fields but you should check that it builds against head as of bfb2fd5f66183454cfe8771595df09c0f23c7efb

OK, my SIIG cable arrived, and I have yet to test with it. I'll plug in via a hub for safety at first, and to test with udbc(4) as the client end (I used to use udbp(4) for this way back when), I'll need to pass through a USB device in KVM to my FreeBSD VMs, which at libvirt level requires an XML edit and restart.

In D56013#1281115, @ivy wrote:

./boot type=dir uname=root gname=wheel mode=0755 tags=package=bootloader,utilities

i don't think this is right (and based on what i remember of mtree-to-plist, i'm not sure it'll even work). /boot should be owned by the bootloader package; if something is adding a package=utilities tag to it, whatever's doing that should be fixed.

not tested, but based on code inspection this looks fine. it's better not to add the correct package= tags on the new entries for now, instead we can do that for the entire file and test it all at once, since that's created subtle issues in the past.

./boot type=dir uname=root gname=wheel mode=0755 tags=package=bootloader,utilities

LGTM

In D55915#1280245, @kib wrote:

You only write a single value into the specified offset, right?
This should be clearly explained in the man page addition.
Or consider adding a possibility of writing the series of values starting at the given offset, of the specified width for each value (IMO it is fine as is, but needs to be properly documented).

In D55915#1279706, @jhb wrote:

I think rather than trying to overload -B, it would be better to just use a different getopt() letter for this mode. I would suggest using -R for reading from a BAR but keep 'D' as an alias for backwards compatibility, and using -W for writing into a BAR.

If you remove all of the TB3 PCI IDs from the NHI and PCIB drivers, the driver is basically useless for TB3 since it won't probe and attach to anything but generic USB4-capable controllers like the "Pink Sardine" ones (as-is).